Блог NunDesign

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

Бывает так, что встречаются люди, и говорят: “а вот нефигово бы забабахать такой-то крутой сервис, который будет офигительно нужен такой-то аудитории! Все считают, что нефигово? Так давайте, вместе и забабахаем!”, они — единомышленники, они собираются командой, у которой есть единая цель, и каждый из команды, в зависимости от специализации, выполняет свою часть работ таким образом, чтобы оптимальным образом достигнуть цели. Аналитики анализируют, админы обеспечивают интернет и сервера, программеры пишут код, дизайнеры рисуют интерфейсы, маркетологи работают с рынком. Бывает так, что каждый из команды находится в системе, где все элементы системы настроены на достижение практически одинаковой цели. Я знаю несколько таких команд, в той или иной степени похожих на то, что описано.

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

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

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

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

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

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

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

И тут я сделала тот поступок, из-за которого не спала всю ночь, переживала, меня гложет совесть, и я всё время думаю о том, как же теперь исправить ситуацию. В общем, через голову этого арт-директора я обратилась к руководителю подразделения. Спросила, в курсе ли он, что рисуют их канадские дизайнеры. Выложила ему эти несколько “утверждённых” скетчей и спросила, кто же их *утвердил*. Попросила обсудить ситуацию и прояснить нам - неужто же это мы такие тупые и не видим красоты там, где видят красоту канадские дизайнеры и их директора? Чего же мы не понимаем в качественном дизайне?

Через несколько минут получила ответ. В котором мне написали, что “с ситуацией будут разбираться там, в их офисе”, что эти утверждённые эскизы — (дословно) барахло, что кроме самого этого арт-директора их никто не видел и не утверждал, и (дословно) “Таня, если бы вы рисовали ТАК, вас бы УЖЕ всех уволили”. Т.е. нам эти работы в пример не брать, примером “качественного дизайна” не считать, а с процессом и критериями оценки эскизов канадским арт-директором разберутся в ближайшее время.

Но помимо этого я-то знаю. Что этот канадский арт-директор пока что ещё никакой не арт-директор, это паренёк-дизайнер, с богатым фрилансерским прошлым и неплохим портфолио сейчас типа на испытательном сроке на эту должность, просто очень хочет пройти этот испытательный срок успешно, красиво показаться перед своим руководством очень ответственным руководителем команды дизайнеров, и большая часть понтов — она от чрезмерного усердия в достижении именно этой цели. У него ещё много всего не определено, ситуация подвешенная, он не расслаблен и не может заменить сомнительную цель остаться на должности арт-директора другой, более уместной - качественно организовать работу дизайнерской братии в целом. Я-то это всё понимаю. С другой стороны, если он свои сомнительные цели будет реализовывать за счёт ребят из нашей команды - я молчать не смогу, потому что увольнение неплохого дизайнера — это серьёзное событие, для этого нужен реальный повод, а не высосанный из пальца запонтовавшегося потенциального арт-директора. Своих ребят я защищала и буду защищать полюбому, по крайней мере до тех пор, пока верю в них и в то, что они здесь — на своём месте.

Ага. Вот я и оправдываюсь. Т.е. как будто всё сделала правильно. Только что-то мне неймётся… Своего дизайнера отбила, а канадского паренька подставила (они там на увольнение быстрые, я это точно знаю, у них текучка кадров приличная, а это именно то, чего я с таким трудом пытаюсь избежать в своей команде).

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

Много пишут про мотивацию сотрудников. Пишут о том, что людей к работе надо МОТИВИРОВАТЬ, деньгами, отношением, корпоративными тусовками и прочими мелкими радостями жизни. При этом я понимаю, что мелкие гадости жизни могут испортить любое, даже самое сильное желание сделать свою работу, и сделать её качественно, но. Пишут много так же о том, что сотрудник, который приходит на работу, изначально (должен был бы быть) мотивирован на эту работу, т.е. он пришёл добровольно, на заранее оговоренных условиях, он захотел (!!) работать эту работу именно в этой компании. И если бы всё происходило по простым схемам, то в мире не было бы ни одной неудачной компании, никто бы и не писал о стимулах и мотивации (возможно, писали бы больше о том, как каждому отдельному человеку найти своё призвание). Откуда же в реальной жизни возникают трудности в управлении компаниями, командами, каждым по отдельности? Вообще, с чего начать анализ?

Люди - все они, разные, по характерам, по типам, по специальностям, все они, все мы — хотят работать или нет? Правильно ли утверждение, что желание работать — это нездоровое желание? Можно хотеть есть, или сексом заниматься, или красивую игрушку купить, (но чтобы поесть — нужно немного поработать! ©обительзла1), можно желать самоутвердиться (к примеру, как специалист в своей области), можно желать властвовать, и для удовлетворений всех этих естественных желаний ПРИХОДИТСЯ работать эту самую работу. Но как же тогда с мотивацией? Кто же тогда на самом деле ответственнен за её наличие? И какое место здесь займёт самодисциплина каждого отдельного сотрудника? Мда. Не очень хочется приводить примеры из офисной жизни, попробуем издалека, на не “рабочих” процессах.
(more…)

Многие старички в веб-девелопменте отмечают великую разницу в объёмах доступной информации по разработке в, скажем, конце прошлого века (сравнительно с настоящим моментом). Дизайн, программирование, проектирование, есть масса бумажной литературы, электронных книг и видеоуроков, просто онлайн-документации. Проводятся конференции, семинары и прочие мероприятия для обмена опытом. И здесь, конечно же, Москва в фаворе (не в упрёк, я же понимаю, что ничего не происходит само по себе - просто больше энтузиастов, больше людей, которые не тупят над проблемами в местечковых болотцах, а готовы организовать движняк, потратить на это время и бюджеты, найти спонсоров, организовать, пригласить, проанонсировать - это тоже тяжкий труд, я знаю). Украина сейчас тоже подтягивается по количеству интересных мероприятий, тот же 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 организациях и всегда испытывал “кайф”, при том что каждая следующая была на порядок лучше, вменяемей и кайфовой чем предыдущая

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

Из прошлого поста о верстальщиках и программерах могло сложиться (и у некоторых, судя по переписке, сложилось) неправильное впечатление: да, я писала о кривом коде, порождаемом визуальными редакторами, да, я недоумевала - как же так, не ВасиПупкины, не начинающие веб-дизайнеры — вполне себе сложившиеся программисты, и вдруг - режим Design в VisualStudio для быстрого создания типовых форм. Но ведь и фраза “а что, у нас программеры уже напрочь ручками код перестали писать?” не имеет ничего общего с рекомендациями “писать” в блокноте, ни разу. И более того, когда касается не программирования, а вёрстки - своим ребятам я категорически запрещаю верстать в notpad`e, а программерам я вообще не указ. Просто - чем больше проект, тем меньше работы для дизайнера и верстальщика в проекте (когда уже написана общая таблица стилей, уделить пять минут тюнингу новой части сервиса — когда продумана и разработана концепция иконочек, маркеров и прочих фишечек, нарисовать новую козявочку — никакой сложности), но тем больше работы, связанной с тем, что ломается и “едет” дизайн после того, как программер поработал с проектом.

И здесь работа не для тестировщика, ему-то что, он таск отправил - что видит, о том и написал. А техническому дизайнеру - разгадывать шарады, почему что-то куда-то уехало. На днях звонит канадский программер, говорит — “я там ничего такого особого не делал… а блок с прелоадером (очередная крутящаяся козявочка с надписью “Loading…”), которая показывалась всегда в центре экрана, уехала в левый верхний угол“. Что делает дизайнер? Правильно, ломится проверять таблицу стилей - вдруг где-то правила сбились, вдруг где-то и в самом деле неграмотно написано… вроде всё честно. Ломится в код - бывало такое, когда программер добавлял контейнер (div) в код “не правильно”, а где ему показалось удобнее, но в коде тоже всё корректно. В чём глюк, разумеется, нашла - раньше прелоадер показывался на довольно простых условиях, когда генерилась таблица статистики, или подгружались ещё какие-то объёмы данных; но сейчас сценарии усложнились, и блок с картинкой (с тем же, как бы, идентификатором) программеру пришлось сделать серверным контролом. Т.е. с динамически создаваемым именем идентификатора. Т.е. правила, в соответствии с которыми прелоадер показывался в центре экрана, правила, которые назначались блоку по имени идентификатора, больше не применяются - имя-то меняется. (more…)

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

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

Новички вообще-то не знали, что для того, чтобы сейчас неперетруждаясь получать свою европейскую зарплату этот человек вообще-то в трудный период становления компании, когда нужно было со сложными и яркими проектами ворваться на рынок, пробить свою нишу - этот человек полтора года работал за 400-500-600 едениц по 12-14 часов в сутки. А сейчас - что, сейчас - есть заказчики, есть (стабильно) работа, есть ниша, и значительная заслуга в этом - того самого старичка. А новичкам обидно, что же это получается - это нужно год работать за зарплату не выше средней по городу для того, чтобы к тебе стали относиться серьёзно? И это серьёзное отношение выражать в деньгах и ласке? А описанное выше - преданность, лояльность - для новичков это блеф и отмазка чтобы денег не платить. И отсюда тоже в значительной степени - обиды, недопонимание, капризы. И что-то мне подсказывает, что лет через 10-20, когда станут они (не все, но если кто-то) президентами компаний, возможно - IT-шных, сильно поменяют они своё мнение и отношение к новичкам и к верным старожилам… Но.

Сколько бы новички не обижались, сколько бы ни оправдывали текучку кадров в компании HR-менеджеры типа “незаменимых у нас нет”, многое зависит и от руководства компании. Когда-то ещё в ЖЖшном блоге было несколько хороших дискуссий (к примеру, в записи “Офисные разработчики - текучка кадров“) о сладких пирожках для сотрудников - какими бонусами и прелестями жизни можно удерживать специалистов в одной компании, уменьшать круговерть. А сегодня читаю вчерашний блогопост Квакина “Сыр для специалиста” - всё о приманках для сотрудников, готовое пособие для руководителя компании:

«…Я — монстр карьерной эквилибристики. Люблю (и умею) находить хорошую работу. Присаживаюсь плотно, монументально и комфортабельно, даже если лениво присаживаюсь на несколько месяцев. Никогда не писал-рассылал «резюме»; всегда приглашён и обласкан знакомыми и незнакомыми почитателями качественной работы за внушающие доверие суммы. Но даже сейчас, когда я артствую в спокойной и сытной крейсерской гавани — меня можно сманить привлекательным стартапским кавардаком.ышесказанное, звучит как мантра. Это и есть мантра, благопретворённая в жизнь. Много всякого было в дороге. Решил составить бессистемный список «условий», испробованных в разных местах, и поговорить с вами о важности отдельных пунктов.»

Блин. Весь мой текст, куча букв только для того, что бы попиарить ссылкой пост Миши Квакина, признаю.

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

В комментариях подняли интересный вопрос, актуальный не для всех вероятных читателей этого блога, скорее для тех, кто работает в софтверных или дизайнерских компаниях и где принята командная работа. Что такое хорошая, сработавшаяся команда, от чего зависит успешность командной работы, в какой степени зависит от авторитета и профессионального уровня тимлидера (team leader)? Вытаскивая из дискуссии:

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

во-первых, командное деление — прерогатива продуктовых компаний. проектоориентированные компании не имеют монолитных команд. есть пул разработчиков и пул проектов. это эффективнее. nothing personal, никакого масонского заговора, just business.
во-вторых, ни разу не видел тим лида, который был бы слабее подчиненных. разве что в аспектах. но никак в целом. все знакомые мне лиды люди с колоссальным опытом девелопменат. а успешные лиды — еще и с колоссальным опытом управления. именно это и дает им авторитет. хорощий человек — не профессия.
в-тетьих, было бы ошибкой думать, что при увольнении одного сотрудника начнется массовый исход. я пытался как-то сорвать команду полностью. я не был лидом, но разговоры подрывные вел, каюсь. никто. команда просто развалилась. даже если уходит тим лидер, не всегда уходит команда. а уж если девелопер уходит… отряд не заметил потери бойца, называется картина. это миф, нет в реальности такой единицы, как комнада. во всяком случае я не видел ни разу. это только во дворе каждый за каждого, в бизнесе каждый сам за себя.

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

(more…)

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

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

Чётко видно два подхода. Одни говорят - я в самом деле не знаю, как это сделать, и не встречал, как это кто-то делал бы. Но попробую разобраться. И идёт разбираться, кто-то быстрее, кто-то медленнее, но, в конечном итоге, всё сростается и основная здесь проблема - получить новичку время на исследование-обучение + договориться с дизайнером, что и как они будут делать. Вторые дизайнеров за авторитет не почитают ни в каком приближении, и если эти “художники” добавляют ему каких-то проблем, просто отшивают их, мол, нереализуемо. А заказчики - они что, они качество кода оценивать не будут, для них всё качество заключается в работает/не работает, зато на красивые фантики (заставочки, кнопочки, иконочки) покупаются моментально. Если в компании чрезмерно уделяется внимание внешнему виду в ущерб логике и коду - это плохой метод, потому что в конечном итоге бесперспективный. Но если есть здоровое понимание важности грамотного и красивого интерфейса для утверждения (и дальшейшего развития-совершенствования) проекта, а программер в силу недостаточности опыта не догоняет принятую в качестве стандарта модель - начинается конфликт. В самом деле. Дизайнер, вместо того, чтобы продумывать форму и сценарии показа форм, отношения цветов и отрисованные элементы становится дурацкой пешкой, которая бегает между программером и PM, торгуясь - будем мы делать ТАКОЙ интерфейс или нет (потому что именно ЭТОТ программер, в отличие от ПРЕДЫДУЩЕГО, пока не может быстро реализовать задуманное с графикой). Фигня какая-то. (more…)