Блог NunDesign

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

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

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

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

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

(more…)

Уже сейчас, новичкам-дизайнерам, которые только-только, читаю о значимости “командной работы”. Уже сейчас, среди совсем новичков и среди “почти не новичков”, ориентируюсь на мелкие командные пары-связки “рисующий”+”верстающий” (немного в прошлом посте об этом уже было, и о трудностях даже в парных связках), выравнивая по скорости работы, по характерам - к примеру, на сегодняшний день “рисующий” рисует эскизы приблизительно с той же скоростью, как его в паре верстающий эти эскизы завёрстывает в сайты с шагом -1 (т.е. к тому времени, когда у верстающего заканчивается работа над сайтом N, рисующий как раз заканчивает работу над сайтом N+1) - это очень здорово, но получится ли так же успешно у следующей связки? Пока неизвестно, и ставить их на поток в ответственных больших сайтах страшновато (тем более объём по безответственным простым сайтам ещё огромный).

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

Вот берём к примеру проект. Большой. Работает команда (не считаем менеджеров-управленцев), из разработчиков - 8 программистов на нашей стороне и чуть меньше (но не менее квалифицированных) - на заокеанской, с нашей стороны -+ один дизайнер и + один тимлидер, к которому сводится весь код, который и выкладывает “сегодняшнюю” версию на публичный тестовый сервер. И проект, кажется, интересный, и не только идея - но и… как это называется? Когда, если будет закончен и запущен - станет чудо как престижным, потому что уже сейчас потенциальные, почти-почти реальные партнёры - это монстры всея сети, имена которых известны даже школьникам, и уж, кажется - долой совдеповское представление о том, как должна быть организована работа! Ведь не важно - как после, через пол года, через год повернётся ситуация, но написать в том же портфолио-резюме строчечку о том, что участвовал в таком масштабном, для таких известных… это же грандиозно! Значит, не может быть в командной работе зашоренности на реализации логики отдельного модуля!

И опять сталкиваемся с тем же. Что-то программер ваяет, сочиняет, пишет, в восемь вечера коммитит в SVN свой (работающий) кусочек кода, который включается в проект и выкладывается на тестовый сервер. Где СамыйОтветственныйУправляющий тестирует (для него это не модуль, для него это - страница сайта, на которую он заходит и кликает на ссылочки, заполняет формочки), смотрит с ужасом на страницу, про которую ему типа уже доложили, что “сделано”, и говорит - ребята! Здесь же ничего не сделано! Это нельзя показывать президенту компании! А презентация для него состоится через два часа!

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

Чисто формально. Реально с таким формальным подходом они подставляют не только дизайнера (Таня, здесь же ничего не оформлено! - Да этот модуль только что появился, когда бы я успела? (Тех.директору) - Чем вы там все занимаетесь? Это же никому нельзя показывать! - Но программист же сделал логику, как заявлено, логика-то работает? - Нифига здесь не работает! Это нельзя никому показывать! Уберите пока эту страницу из проекта вообще, чтобы они даже случайно сюда не зашли, пусть лучше UnderConstruction, чем эта фигня! Вы же целый день там работали, неужели нельзя было сделать по человечески?) , но и себя, в конечном итоге. Потому что там, у главного руководства, будет поставлена галочка: модуль программиста А не выполнен, работа не сделана.

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

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

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

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