Блог NunDesign

Я понял – это намек, я все ловлю на лету,
но непонятно, что конкретно ты имела в виду?
Вот я не понял.
© НС

Интересно, все ли постановщики задач для разработчиков мечтают стать телепатами, или даже телепатами наоборот – чтобы не описывать задачу словами, а вбивать её разработчику прямо в голову, со всеми формальными оборотами, чувствами, впечатлениями, чтобы у разработчика мгновенно появлялось видение результата его работы, полностью соответствующее задаче? Как часто постановщик, в документах, на досках, на пальцах объясняющий разработчику, что ему нужно сделать, не может перешагнуть барьер непонимания (или недо-понимания) задачи?

К примеру есть система, в которой нужно что-то изменить. У тебя есть видение существующей системы (набор исходных данных), видение новой системы (цель, к чему стремиться), и есть метод решения. Ты даёшь постороннему человеку описание своего видения обоих систем и передаёшь метод решения, в расчёте на то, что это описание у него трансформируется в его видение, полностью соответствующее твоему.
На самом деле так бывает редко (а в деталях, так и никогда), потому что описание – вербально, оно не передаст ни образы (запахи, чувства), ни опыта, который позволит увидеть эту систему живой, ни сути, поэтому то видение, который человек у себя создаст по твоему описанию, будет са-а-авсем другим. При этом в соответствии с теорией относительности всего по отношению к всему очень может возникнуть такая ситуация, что даже при наличии разных видений у постановщика и его исполнителя результат преобразования исходной системы в требуемую получается очень даже удовлетворительный. Только что-то редко так бывает.

Зато часто бывает по-другому. Разумеется, прежде, чем позволить исполнителю начать процесс преобразования, постановщик может убедиться в том, что задача понята правильно. Если нет, то повторять (изменять, дополнять) процесс постановки до тех пор, пока не убедится в том, что его понимают правильно В ДОСТАТОЧНОЙ МЕРЕ для того, чтобы начать работу. Это довольно забавный и трогательный этап, особенно, если смотришь на него со стороны, не являешься ни постановщиком, ни исполнителем. Эмоции, повышенные тона, напряжение возрастает… Почему?

1. Возможно, постановщик даун. Не может словами выразить, что же и с чем нужно делать.

1. а) Нет картины исходных данных. Встречается довольно часто: постановщик с заказчиками, аналитиками и прочими ответственными людьми обсасывает проблему, можно ли её решить, если можно – то как, и почему так, и в результате у него накапливается изрядное количество мелочей, каждая из которых незначительна сама по себе, но незаменима для построения живой системы. Часть этих мелочей через некоторое время становится “чем-то очевидным” для него, и он начинает полагать, что опираясь только на здравый смысл и обычный житейский опыт каждый первый (разработчик) и так поймёт их необходимость в системе. Т.е. либо не считает нужным передавать исполнителю информацию обо всех этих мелочах, либо ему даже не приходит в голову, что об этом тоже нужно говорить. Исполнитель недополучает исходные данные, соответственно, не понимает, что от него хотят.
2. б) Не даётся полное описание требуемого результата работы, цели. Тоже много разных причин, одна из типичных – конечному разработчику это не нужно. К примеру, потому, что это, на самом деле, корпоративная тайна. Поэтому изыскиваются такие слова и обороты, которые скрывают реальную цель работы, отрисовывая некую псевдо- цель, подобную исходной настолько, что исполнитель, сам того не зная, как раз и сделает то, что нужно заказчику. Но нарисовать мнимую цель, действительно подобную реальной – это, знаете ли, великое искусство, не каждому дано, и, как следствие, редко срабатывает так, как ожидалось.
   -
   Ещё одна часто замечаемая причина – отсутствие понимания цели у самого постановщика. Т.е как бы он предполагает, что понимание есть, но именно в процессе постановки непосредственному разработчику, уже на этапе повышенных тонов и обид, обвинений во взаимной тупости выясняет (-ся), что — да, разработчик указывает ему на, к примеру, технические несоответствия, и в относительно благополучных командах это заканчивается перекраиванием задачи, в соответствии с другим уже пониманием цели. А бывает и такая причина: постановщик действительно не понимает чётко что нужно сделать и перекладывает ответственность на разработчика, расчитывая на его опыт, на то, что он, такой умненький, сам сведёт концы с концами и догадается, что же нужно было сделать.
3. с) Методы решения не вписываются в процесс преобразования одной системы в другую. Конечно, чаще всего бывает, что ведущими будут причины а) и б), но при этом постановщик вообще не озабочен тем, чтобы дать полное описание исходной системы и цели, упор же делается на метод решения, который как будто бы подробно описывается, а исполнитель всё равно не понимает, что же ему нужно делать и, главное, зачем.

2. Возможно, разработчик даун. Разумеется, приятно работать со звёздами, которые всё схватывают на лету, предугадывают следующую фразу и даже при небезупречной постановке умудряются сделать работу лучше ожидаемого. Средний разработчик среднее количество рабочего времени среднего уровня сложности постановки воспринимает на среднем уровне достоверности. Что означает, что даже при подробной и вполне качественной озвучке 1.а), 1.б) и 1.с) он всё равно будет “тупить”. Да по каким угодно причинам. Сонный после безсонной ночи (ребёнок плакал, девушка требовала внимания, у друга день рождения) с временно пониженной способностью воспринимать информацию. Недостаточно квалификации у разработчика (он ли не “семи пядей”, или задача на самом деле сверх традиционного уровня сложности для существующей команды). Нет цели понять (скучно ему, не зажигает задача, приступ мозговой лени, слизни одолели).

Конечно, бывают ситуации, когда именно повышенные тона и эмоции либо “пробуждают” разработчика, либо открывают глаза постановщику на то, что он вбивает в несчастного непродуманную глупость. Но как же хочется всегда обходиться без напряжения, как же хочется, чтобы между постановщиком и разработчиком были более адекватные каналы передачи информации. Ну да. Напрямую, в мозг. Или каким-нибудь ещё альтернативным методом.

По поводу альтернативных методов можно с примером. И в самом деле, как выше и было написано, очень много для понимания задачи значит опыт (и жизненный, куда же без него), и по специальности. К примеру, ставится задача талантливому, умному и сообразительному дизайнеру, у которого вовсе не было никаких приступов тупости. И изрядный (можно уже сказать так на сегодняшний момент) опыт рисования интерфейсов для веб-сайтов. Но не особенно значительный опыт рисования интерфейсов для веб-сайтов с динамическим контентом – так, всё больше рекламные сайты, один раз сверстал почти открыточный макет, так он и живёт. И вот один за другим приходят проекты, где дизайн нужен для динамического контента, начиная от произвольного (для разных групп пользователей) количества элементов меню и субменю и заканчивая текстами, которые добавляют пользователи. И раз за разом дизайнер рисует эскизы, умиляюще красивые, такие, какие с первого раза нравятся заказчику, но, мягко говоря, не особо удобные для динамики. Первые проекты приходилось контролировать и переделывать оформление тех блоков, которые при всей их красоте были не особо уместны для конкретной задачи. Потом были разговоры о том, что надо, надо, надо обучиться вёрстке, что пока не будет пережитого лично тобой опыта вёрстки, внедрения твоего дизайна в живой проект, пока не увидишь причины, почему так а не иначе, на словах не получается объяснить, в чём разница “презентационного-рекламного дизайна” от “дизайна для динамического контента”, и желающих помочь, от тимлидера до остальных верстальщиков вроде хватает, и книг, и работы, но… то одно, то другое, то времени нет, то жених ждёт, то как-то прям сегодня не хочется…

На последнем проекте, уже скорее с целью эксперимента, исправив в эскизе ряд совсем уж явных ошибочек (к примере, в профайле юзера должен был показываться его мейл, но этот блок был оформлен в размере по ширине соответствующем первому попавшемуся адресу. Предложила в этот блок на эскизе поставить другой, реальный, взятый из корпоративной переписки, с в три раза большим количеством символов и объяснить поведение этого блока – будет он становиться шире, в зависимости от размера мейла пользователя, или будет мейл частично скрываться, чтобы сохранить красоту начального дизайна), объяснив очередной раз про динамический контент и про то, какие элементы будут куда вытаскиваться из базы, ушла в отпуск. Эскиз приняли, порезали, внедрили. только вот блок, следующий после дескрипшина, визуально панелечкой выровнян по вертикали с большой заметной кнопкой. И это, разумеется, очень важно для дизайна. И, разумеется, маркетологи, данные которых выводятся на этой странице, гады такие, вбивают дескрипшины разного размера. А нужно (по дизайну) чтобы текста хватало на четыре строки. А они, лентяи, пишут пять слов, вмещающихся в одну неполную. И что делать с несчастным блоком, таким красивым, который следует за дескрипшином, не понятно. То ли продолжать выравнивать по большой кнопке (тогда на кратких дескрипшинах будет дырка в три текстовые строки), либо отпустить размер высоты дескрипшина, тогда красивый блок не будет выровнян по правой кнопке, получается визуальная кривость.

Вот честно признаюсь, можно было изначально на этапе эскиза очередной раз указать на “великое будущее” этого блока, видно было изначально. Но тогда сколько ещё проектов, сколько ещё элементов в эскизах придётся под диктовку переделывать, сколько раз повторить практически одну и ту же лекцию про динамический контент? В таких ситуациях лучше, если дизайнер уже сам переживёт эту проблему, запомнит её и не будет смешно настаивать, чтобы “пользователи вводили четыре строки текста в этом дескрипшине, ибо это важно для дизайна” (что по любому невозможно будет заставить сделать тех маркетологов, которые ещё и не наши, а заатлантические). Будет опыт. Будет на пол повторяющейся лекции меньше. А всё потому, что я не могу передать часть своего видения системы, включающего опыт проектирования-рисования-вёрстки-интерграции макетов для динамического контента, напрямую в мозг моему хорошему, талантливому дизайнеру, который рисует эскизы для наших проектов.

Многие старички в веб-девелопменте отмечают великую разницу в объёмах доступной информации по разработке в, скажем, конце прошлого века (сравнительно с настоящим моментом). Дизайн, программирование, проектирование, есть масса бумажной литературы, электронных книг и видеоуроков, просто онлайн-документации. Проводятся конференции, семинары и прочие мероприятия для обмена опытом. И здесь, конечно же, Москва в фаворе (не в упрёк, я же понимаю, что ничего не происходит само по себе – просто больше энтузиастов, больше людей, которые не тупят над проблемами в местечковых болотцах, а готовы организовать движняк, потратить на это время и бюджеты, найти спонсоров, организовать, пригласить, проанонсировать – это тоже тяжкий труд, я знаю). Украина сейчас тоже подтягивается по количеству интересных мероприятий, тот же UA WEB, те же конференции по маркетингу. Но всё равно мало и редко, в Москву же не наездишься. Те же РИТ-РИФ-КИБ так и остались в мечтах, потому что “а здесь кто работать будет?” И вот ещё одна апрельская тема — IT-Online пригласили Эдварда Йордона, автора книги «Путь камикадзе» (Death March) провести однодневный семинар (один день в Москве, один в Питере) «Управление безнадежными проектами».

Коротко о том, о чём будет идти речь: будут обсуждаться вопросы “в области управления проектами: как успешно выполнить самый безнадежный проект? Существует ли эффективный способ вдохновения команды на достижение поставленной цели? Как сэкономить время, отбросить сомнения и достичь потрясающих результатов?”

Рассматриваемые темы:

• Политика в безнадежных проектах
• Переговоры во время безнадежного проекта
• Управление персоналом в безнадежном проекте
• Процессы безнадежного проекта
• Динамика процессов
• Симуляторы и «военные учения» для моделирования безнадежных проектов
• Контроль в проектах «смертельного марша»
• Инструментальные средства в «смертельном марше»
• «Безнадежный проект» как стиль жизни

Программа мероприятия предназначена для директоров проектов, руководителей команд разработки, менеджеров проектов, архитекторов, руководителей ИТ-департаментов, а также менеджеров высшего звена.

А что, мне лично было бы интересно послушать умных людей, может, подкинут какую-нибудь идею для нашего офиса. Хотя, если я правильно понимаю, обсуждаться будут именно “безнадёжные проекты”, а не “безнадёжные команды” и “безнадёжные компании”, но в целом, если уж затрагивается тема “управления персоналом”, значит, всё одно полезно. Для нас важно понять источники всех сложностей, с которыми мы сталкиваемся, как украинская команда канадской компании. В обсуждении прошлой, вчерашней заметки “Офисное дизайнерское и менеджерское” на ya.ru, Lisa очень точно (хоть и не приятно в этом признаваться) подметила одну вещь:

Lisa
Тут проблема в том, что ты находишься в положении стрелочника, удаленного филиала, на которого очень удобно спихивать проблему и ответственность, но мнение которого по поводу правильного документооборота никто не спрашивает.

Nundesign
Точно знаю, что даже работая таким удалённым филиалом, можно красиво и грамотно организовать цикл работ. Прежде всего для этого нужно, чтобы все элементы системы хотели того же. Иначе – сознательный или неосознаваемый саботаж, увы.

Lisa
Здесь проблема как раз в том, что очень сложно организовывать что-то красиво и грамотно, когда тот, кто заведомо находится в “старшей” позиции может через твою голову давать задания твоим сотрудникам.
Скажем, для меня это одна из самых больших проблем была – найти баланс между “я – всеобщий секретарь” и все вообще идет через меня и “я не знаю, кто из клиентов какие задания надавал моим сотрудникам”.
Я очень хорошо знаю, что и там, где не ты главный, можно очень много порядка навести Если поставить перед собой такую задачу. Но преодолевать сопротивление со всех уровней – очень тяжело. И сбрасывая с себя хоть какой-то уровень – ощущаешь облегчение. Причем как вариант – отказываешься от обучения и выращивания подчиненных и делаешь всю работу самостоятельно, такой этап тоже был и он проще и порой благодарнее, чем отказ от начальников

C одной стороны, совет красивый (и когда-то работавший), но сейчас, при нынешних объёмах это означает только одно – отказаться от значительного количества проектов и вернуться к потоку 2005-го года. Если же нет, если же соглашаться на те же объёмы, что и сейчас, в любом случае нужно оптимизировать командную работу, отлаживать схему управления проектами двумя командами – канадской и украинской (на самом деле тремя, и даже четырьмя, но это детали). Потому что периодически сотрудничество в самом деле напоминает несимметричное распределение настроений – одни бьются головой об стену, пытаясь, другие занимаются поиском виноватых и переводом стрелок. И, главное, методы получения достоверной информации зачастую бывают затруднены и походят на разведку.

Как обычно, после (извиняюсь) многобуквенной вступительной речи переходим к реальным примерам из жизни. В районе плюс минус нового года у нас было много заказов на разработку маленьких рекламных сайтов – и на эскизы, и на порезку-вёрстку. Объёмы были чуток сверх человеческой нормы, ребята работали в том числе и сверхурочно, и я вместе с ними и рисовала, и верстала в зависимости от того, куда был перекос нагрузки, и даже обсуждалось, что нужны ещё люди. Потом объёмы начали как-то заметно снижаться, хотя в личной переписке с канадским арт директором тот уверял меня, что всё ОК и объёмы вернутся. И только через пару месяцев, в приватной беседе мне сообщили, что этот арт-директор в посленовогоднее время стал интенсивно собирать команду своих дизайнеров, в офис – и рисующих, и верстающих. И сейчас у него работают около 10 ребят, и ему с ними КОМФОРТНЕЕ работать, потому, что проще поставить задание, проще обсудить на словах и на пальцах (а не сочинять в письменном виде), что он по-прежнему сопротивляется работе с, к примеру, JIRA, хотя у него есть доступ и аккаунт (ни одной задачи он в джире так и не создал), что его в такой схеме не травмирует разница во времени, и оперативность разработки увеличивается на, по существу, рабочий день (на самом деле были стабильные проблемы с тем, что по правилам нашего офиса сотрудники работают с 10 утра до 19, и, понятное дело, если задание присылается в пять вечера, то результат канадские менеджеры смогут получить только на следующий свой рабочий день, или же должны подтверждать согласие оплатить дедлайн, сверхурочные). Таким образом практически произошло вытеснение нашей команды из этой линейки работ, так сказать, естественным образом.

Вообще можно привести много примеров сложности управления распределёнными командами. Здесь и амбиции руководителей, и ответственность за качество, и зачастую откровенно разные цели сотрудничества и прочие тонкости. Не думаю, что наша система безнадёжна, и очень надеюсь, что читатели, участвовавшие или участвующие сейчас в разработке проектов подобными распределёнными командами поделятся своим опытом (как положительным, так и наоборот, чтобы можно было заранее предусмотреть наиболее типичные ошибки), может даже кто-то подкинет полезных советов. Как всегда, жду ваших комментариев!

Не писала сюда потому что завал, потому что опять по 12 часов да без перерыва на обед, потому что настроение такое… авитаминозное. И вообще. Странно было, и особенно контрастно после киевской конфы вернуться в родной офис и окунуться во, в общем-то, всё те же, никак не новые траблы. Другой мир. На конфе люди презентовали, чуть ли не в каждом первом докладе (смотрим в клиентскую часть – вёрстка, юзабилити, тестирование и в менеджерскую – управление, agile, всякий в общем менеджмент) систему. Да, и эта система, по их словам, успешно реализована и успешно работает, во что я даже на словах могу поверить. И дальше – словно возвращение из цивилизованного мира в дикий, и чтобы не начать вообще жалеть о потраченных двух днях на Киев.

Вообще много чего странно. Ещё в 2005-м, 2006-м, ещё в ЖЖ-шном блоге, когда писались заметки о различных офисных проектах, всё представлялось, что описываются обычные трудности новичковой компании, что где-то — от отсутствия опыта, в том числе и менеджмента, где-то — от недосформированности команды профессиональных разработчиков, но в любом случае все проблемы временные и решаемые. Когда три-четыре года назад ЖЖ-шные френды в комментариях писали, что подобные ошибки в управлении – типичные признаки говноконторы, я не соглашалась и утверждала, что мы семимильными шагами шагаем к великому будущему, всему в скором времени научимся и благополучно выпрыгнем из говноконторского уровня. Но три-четыре года — не маленький возраст, и уже стыдно как-то по-прежнему допускать всё те же ошибки, казалось бы, уже пройденные и осознанные. Ежели дитё в 10 лет продолжает сосать соску и писяться в постель – это уже не нормально, не здорóво. И ещё хуже то, что вместо того, чтобы срочно приниматься за исправление, лечение (возможно, хирургическое вмешательство), становится нормой политика “не обращать внимание”, “перерастёт” и “как нибудь само рассосётся”. Ага.

Вообще-то наши говорят, что я всё воспринимаю слишком близко к сердцу, и нефиг так переживать, и уж тем более расстраиваться, и всякое такое. Но я так скажу. Вот, к примеру, я всегда — с далёкого детства — панически боялась сумашедших. Городских, к примеру (вот даже как-то не так давно напомнили об одном из, которого видела и встречала неоднократно). Если приходилось встречать, я просто цепенела, замирала, старалась пройти так, чтобы даже воздухом не коснуться. Потому что рядом со мной оказывался абсолютно другой мир, не обязательно враждебный, но чуждый, иррациональный. Вот эта самая иррациональность, в стиле “летели два крокодила, один направо, другой зелёный”, меня всегда стопорила, я терялась и не знала что дальше делать. Ставка на адекватность и здравый смысл… а так же на отработанные другими IT-офисами стандартные решения для управления командами, проектами и жизнью офиса в целом… Это всё, видимо, из какой-то другой жизни. Попробуем теперь на живых офисных примерах – последних событиях, которые, как я выше и написала, начались с того, что я засобиралась в Киев на конференцию для веб-разработчиков, на два дня.

Приезжаю и узнаю следующее: Ещё в начале недели, как оказалось, один из канадских менеджеров прислал сюда, на Украину, ТЗ и скетч на порезку и вёрстку сайта. Уже бред: во-первых, обнаружились (позже) траблы с почтовым сервером, который канадский, а мы тянем переписку M$ Exchange, и она благополучно глючит, о чём я не единожды писала и администрации, и канадскому админу. И то письмо с заданием попало в очередную перенастройку почтового сервера и ПОТЕРЯЛОСЬ. Ладно, с админскими траблами понятно, недопустимо, но так сложилось. При этом господа канадцы даже не попытались узнать – получили ли здесь их письмо, почему не было уведомления о получении-прочтении-приступании_к_работе. Я уехала в Киев (в среду поздним вечером) в полной уверенности, что на два рабочих дня у моих дизайнеров всё распределено, распланировано и чётко формализовано, т.е. благополучно. К четвергу канадские красавцы опомнились и таки спросили – мол, как там наш сайт поживает? Какой сайт? — удивился наш технический директор. А тот, который вы давно должны были нам вернуть в готовом виде!! Ага, догадался технический директор, вы послали задание почтой, а она у вас (а значит, и у нас) не работает и письмо потерялосЯ. Опять торкается канадский админ с наездом (уже), тот всё-таки занялся проблемой почтового сервера, обнаружил, что письма и в самом деле не ходят, в четверг же ближе к вечеру проблему пофиксил, о чём и уведомил всех. Те же красавцы ещё раз пересылают ТЗ и скетч НАПРЯМУЮ ДИЗАЙНЕРУ, который занимается вёрсткой. Тот начинает работу, но, поскольку время уже позднее, не заканчивая, уходит домой. В пятницу заболевает, и в понедельник продолжает болеть. Про проект никто не вспоминает.

В понедельник я, уже после Киева, приезжаю на работу, спрашиваю, мол, как оно тут без меня? Всё супер, всё в порядке! — говорит техдир. У меня в почте ни одного письма за те дни, когда меня не было. У него по дизайнерским темам тоже ни одного. В джире ни одного нового таска. А ближе к вечеру. Раздаётся тревожный звонок. Где же сайт? Спрашивает канадский управляющий. Извиняюсь, говорю, о чём речь, собссно? Вы, там! Чем вы там занимаетесь! Сайта нет! Мы присылали! Заказчик уже терпение потерял! И всякое такое нелицеприятное в адрес украинского дизайнерского отдела. Начинаю разведку. Сначала пытаюсь через техдира – он говорит, мол, да, что-то такое было в четверг вечером, но у меня писем на эту тему нет, исходников сайта на порезку тоже нет – не присылали. Выясняю через нашего админа. Ага, говорит, письмо есть, только напрямую верстаку, но вытащить его я не могу. Перезваниваю заболевшему верстальщику – он говорит, ага, мол, было такое, но я болею… Вытаскиваю из его машины присланные в четверг исходники. А дело уже вечером (канадцы просыпаются и приходят на работу, когда у нас часа три-четыре дня). Разумеется, в сверхурочном режиме запустили исходники в работу, порезали, сверстали сайт и отправили в Канаду. Успели, все счастливы. Ура. Ура? Млин, с каких это пор задание присылается напрямую разработчику, что такое, унизительно сделать карбан копи любому старшему? Обсуждалось миллион раз, объявлялось как обязательное требование. Таня, ты же типа в Киеве была. Ну и что? У меня всё время был доступ к почте, я всё время была в онлайне в вашем любимом млин MSN мессенджере, у меня ни грамма информации о том, что этот проект вообще был и уж тем более о том, что он был срочным и не по вине украинского офиса к тому же просроченным (из-за проблем с почтовым сервером).

Да, это только один пример подзапущенного за два дня моего отсутствия проекта. Если бы у нас в работе только он был! Ещё много. И веб приложения, и видновз application, на которые надо было скин натягивать, а дизайнеру, славной, талантливой девочке, пришло три постановки задания – от канадского руководителя направления, который ведёт именно эту разработку, от технического директора, который типа ответственный за именно эту разработку, и от тимлидера, который, собссно, и разрабатывает с парочкой подчинённых ему программеров. Канадский руководитель требует одно, тим лидер, глянув свысока на требования канадской стороны, говорит, что в пилотной версии этого ТОЧНО не будет, и для презентации нужно сделать то-то и то-то… И что ей оставалось делать? Показать отрисованный эскиз В КАРТИНКЕ, а в пилотной версии проекта реализовать то, что, грубо говоря, позволено разработчиками и не более. И в процессе пятничной презентации оказывается, что всё плохо, и опять дизайнеры нихрена не делают, и, Таня, я не знаю ничего про ваши технические трудности с реализацией, я вижу не сделанную работу.

И опять Déjà vu. Будто и не было утверждённой модели работы, будто и не обсуждалось, как оптимизировать процессы. Будто опять никто не понимает, что такое приоритеты и как они выставляются, и КОМУ. Будто не обсуждалось всей командой, как и что должно происходить, словно нет команды как таковой, нет командной работы – публика стрелки друг на друга переводит, это не моё, а это не в моей компетенции… Блин. Не в моей компетенции. Какие все некомпетентные, а, главное, равнодушные. Миллион раз было так, что тестировщик, не верно проанализировав баг, постил этот баг на дизайнеров. Я, получив баг, видела, что он чиста программерский и спокойно делала перепост на программера, курирующего этот проект. Нет проблем, не вижу проблем. Но когда человечек, получив “не свой” баг, тупо молчит, мол, это не моё – и всё, трабла зависает, тестировщик уверен, что баг в разработке, программер, который должен был бы этот баг работать, ни разу не в курсе, тот же красавец, который получил баг, сидит занимается (честно и кст., качественно) своей работой.

“Нам главное показать функциональность”. А ведь заплевали недавнюю заметку о перекосах. И вот очередной раз мы сталкиваемся с тем же. Ребятки, вам же объяснили. Что в пилотной версии на самом деле не требуется показывать всю функциональность. Но для презентации должны не только работать четыре из пятнадцати (грубо говоря) кнопок, эта версия должна быть презентабельной, т.е. аккуратной и красивой – а не с накиданными куда попало элементами форм со стандартной виндовой отрисовкой этих форм. И сколько раз рассказывали уже из реального опыта последних лет. Что компанией бюджет выделяется ТОЛЬКО НА ПИЛОТНУЮ ВЕРСИЮ. После чего привлекаются инвесторы, которым эта версия ПРЕЗЕНТУЕТСЯ. И если проект их заинтересовал, они готовы инвестировать в его глобальную разработку, в развитие и маркетинг. И может всё дело только в менталитете потенциальных канадских инвесторов, которые не видят прелестей функциональности без визуального оформления, я не знаю. Но шансы получить инвестиции, если проект в пилоте выглядит привлекательно намного больше. И тогда появляетс бюджет на разработку глобальной версии – оплата человекочасов и сопутствующих расходов, а если нет — то нет. И либо будут положенные по ТЗ для пилотной версии четыре функциональные кнопки + хорошо оформленный интерфейс, либо, уважаемые программисты, ваши 15 функциональных кнопок никому не будут нужны, нет денег – нет разработки. Но программисты стойко отказываются идти на компромисс, ежедневно переводят стрелки “на завтра” (Точно найдёшь время? Точно!), гордятся знанием си шарпа и умением в коде писать все требуемые формы, и очередной раз заказчик получает прогу в формате дизайн отдельно, сама функциональная, но не оформленная прога отдельно. А мне спустя время управляющие жалуются на то, что “те потенциальные инвесторы купили у других подобную же хрень. Которая хуже, и глючит, и не масштабируемя, и опций намного меньше, но с симпатичным и продуманным интерфейсом, купились на конфетку”. Мол, а украинские дизайнеры опять облажались и подвели.

Я ж говорю – слушаешь рекомендации о проектировании, читаешь умные книги, смотришь на примеры огранизации работ в удачных компаниях или, как минимум, менее… детских… И понимаешь, что, может, и не правильное это решение, что проще забить и попытать счастья и применить свои способности где-то в другой конторе, но нифига. Мы ещё поборемся. Обучимся. Настроим. О, вот ещё по теме вспомнила пару интересных блогообсуждений. Anatolix в заметке “О пользе NDA” осудил (очень обоснованно, кст.говоря) пост Димы Малина о работе в Рамблере. Не могу не процитировать Диму, это ведь зеркало!

Больше всего меня веселят диалоги с менеджерами проектов:

- Почему лажа с дизайном?
- Ну так дизайнеры нарисовали. Я им говорил! Но я же не буду вмешиваться в их работу.
-Ну вернул бы им такое г… обратно.
- Ну так я вернул, а они мне такое же, только зеленым цветом нарисовали.
- А что с аутсорсом?
- Какой ж аутсорс при своих дизайнерах?
- Ну как ж можно так проект было запускать?
- А иначе и не запустили бы вообще.

- Слушай, а чего твой проект конкурентных преимуществ то не имеет? Чем он лучше проекта YY у Яндекса?
- Ну… главное преимущество то, что он у нас вообще есть. Между прочим, у нас есть отдел маркетинга, вот пусть они и решают что там да как… Они ж у нас за стратегию отвечают.

- Здесь есть очевидная нелогичность в интерфейсах. Ребенок даже увидит. Чего не поправил то?
- А это отдел интерфейсов, их епархия. Они меня не проконсультировали.
- А ты их попросил?
- Ну да. Это было еще в ноябре, с тех пор они чего-то молчат.
- Узнал почему?
- Ну не моя эта работа их домогаться…

- А ТЗ на этот сервис есть? В какой форме поступила задача в отдел интерфейсов?
- Стоп! У нас атмосфера стартапа, у нас креатив! А эти всякие ТЗ только тормозят нашу работу. Мы друг друга с полуслова понимаем…

При этом самый показательный коммент самого Anatolix`а:

просто “кайф” это субъективное впечатление, а поведение менеджеров объективное. Я работал всего в 3 организациях и всегда испытывал “кайф”, при том что каждая следующая была на порядок лучше, вменяемей и кайфовой чем предыдущая

И я не буду напоминать, что уважаемый Анатолий Орлов – без сомнения умничка, талант и заслуженно работает во вменяемой компании – это все и без моих цитат понимают. Но так же все понимают, что есть реальность, и в этой реальности количество вменяемых контор конечно, считаемо по пальцам, остальных – несчётно, среди которых есть совсем бесперспективные, и есть такие, которые хотя бы пытаются настроить тональность для здорового звучания. А можно и снобом прикинуться, свысока глянуть, осудить “долбоебизм” менеджеров. Ну и ладно. Что-то я разошлась, это уже другая тема, с другой стороны. Давно не писала, и вот понесло.