Управление процессом разработки
📅 Опубликовано:8 мая 2011
Это статья из старого первого блога, который сохранился только на archive.org. Все старые статьи помечены тегом 🚨 старое
Давно хотелось поразмышлять на тему управления веб-проектами, техническом менеджменте в веб-разработке, организации работы команды веб-разработчиков, организации технического процесса разработки веб-проектов, ну, или как вы это там называете?
Итак, начнем-с.
Для начала разберемся с действующими лицами. Так как будем рассматривать работу небольшой веб-студии, о таких «экзотических» специальностях, как: администратор веб-сервера; сеошник; контент-менеджер; рерайтер; копирайтер; тестер и других — на время забудем. Все-таки наша абстрактная веб-студия не такая уж и продвинутая, чтобы позволять себе держать в штате или работать удаленно с подобными «сомнительными» специалистами :) Тем более, если допустить существование взаимосвязей со всеми этими представителями интернет-фауны, мы на долго погрязнем в осмыслении этого милого и веселого процесса — разработки веб-проекта.
Для удобства сведем все разнообразие разработчиков к трем специальностям:
- дизайнер(ы);
- верстальщик(и);
- программист(ы).
А также добавим еще одну специальность или должность, или как вам больше нравится думать об этой сущности — технического менеджера (ТМ). В данном случае мне нравится такое название. Эту должность, специальность или может состояние? :) Можно называть по-разному. На буржуйский манер — тимлидер. На совковый манер — заведующий процессом разработки :). Ну и другими разными названиями, кому как больше нравится, все равно деятельность этого существа как его не назови, будет примерно одинакова, в каких бы коллективах он ни был. Причем в некоторых схемах этим лицом будет являться кто-то из вышеперечисленных представителей наших обобщенных специальностей. Но об этом позже.
Для начала нужно разобраться, в чем же состоят его обязанности и полезные свойства :).
ТМ должен являть собой одного человека на один крупный проект. Если брать огромные проекты, скажем, поисковая система и сопутствующие сервисы, то здесь конечно для каждого сервиса или другой более-менее обособленной части проекта, должен быть свой управленец проектом и процессом его разработки. Если говорить об относительно небольших проектах — здесь ТМ может управляться один, если проекты действительно не крупные, что преимущественно и происходит в средних веб-студиях.
Итак, ТМ — это человек, у которого находится под контролем весь процесс разработки проекта. Под фразой «весь процесс» — подразумевается не в принципе весь процесс, то есть не имеется в виду, что этот человек знает досконально все специальности, представители которых находятся под его руководством. Напротив, он может многого не знать, но существует и некоторая граница, правда совсем размытая, подобная песчаному берегу, граница с каждых сторон которой начинаются его взаимоотношения с участниками процесса разработки, причем эти отношения не должны ни коим образом носить директивный или какой-то там еще четко определенный или наоборот — бездумный характер. ТМ должен понимать, именно понимать, о чем он говорит с программистом, о чем говорит с верстальщиком или дизайнером.
Тут возникает вопрос, что именно должен понимать ТМ и на каком уровне? Не может же он понимать все, что говорит программист, все эти сложные названия функций и переменных, многоэтажные конструкции языков программирования и т.д. и т.п. Конечно не должен, а вот что он должен понимать (восстанавливаем в воображении песчаный берег :) — зависит от его квалификации и от бывшей основной специальности, то есть чем он занимался до того как стать техническим менеджером. Таким образом, мы подошли к очень важной детали — наш технический менеджер в прошлом должен иметь опыт непосредственной разработки проекта.
Теперь нужно выяснить из каких предпочтительнее всего специальностей должен вырасти ТМ? Дизайнера мы сразу по понятным причинам отбрасываем. Дизайнер у нас более всех «отрешен от мирской суеты», его не особо волнуют жесткие логические конструкции, разные блок-схемы, графики, функции, переменные и прочие порождения точных наук. Его цель — поймать за хвост синюю птичку и пока в руках все еще чувствуется именно хвост, а не оторванные перышки, родить что-то эдакое, что понравится с первого взгляда милому заказчику :)
Технический менеджер должен ранее, в своем профессиональном прошлом, заниматься непосредственно либо версткой, либо программированием или и тем и другим, да-да, бывают и такие уникальные личности. Мне кажется, что именно из таких людей, которые и программировали и верстали и даже немного «дизайнерили», получаются самые лучшие технические менеджеры. Эти люди перепробовав несколько специальностей, почувствовав их, углубившись в них на достаточный профессиональный уровень, все же не нашли себя в них и решили, что им интереснее именно управлять процессом разработки в общем, а не заниматься конкретными задачами.
В каком-то смысле ТМ для каждого из отдельных специалистов, является маргиналом в области знаний каждого спеца, то есть он как бы и не в курсе всех тонкостей, но и как бы все очень хорошо понимает, что происходит в общем. Исходя из вышесказанного можно предположить, что наибольшее отчуждение и недопонимание, если в данной ситуации можно употреблять такую брутальщину, будет скорее всего между ТМ и дизайнером.
Итак, теперь картина более-менее проясняется. Наш господин технический менеджер — это лицо, имеющее определенной глубины знания из разных сфер веб-разработки и некогда самолично участвовавшее непосредственно в разработке проекта в роли определенного узкого специалиста. Или, позанимавшись узким направлением, решившее расширить свой профессиональный кругозор, занявшись попутно отличной от его текущей работы специальностью. К примеру: сначала верстал, потом углубился в программирование или наоборот, сначала усиленно занимался программированием, потом начал попутно интересоваться и вникать в верстку.
У технического менеджера весь процесс разработки должен находиться под контролем. Он должен знать, чем в данный момент занимается дизайнер. Находится ли он в творческом поиске, есть ли у него идеи, приступил ли он непосредственно к созданию макета, на какой стадии находится макет, что уже понятно, а над чем еще нужно поломать голову, что показать клиенту, а что еще не нужно и т.д. и т.п.
С программистом и верстальщиком должен обсуждать в подробнейших нюансах логику работы проекта, каждой его части, предлагать свои решения, в общем, взаимодействовать в каждом вопросе. Быть своего рода переводчиком между программистом, верстальщиком и дизайнером, являться своеобразным коммуникационным клеем. Держать в голове полностью весь проект, с как можно большим количеством деталей, использовать соответствующие способы организации процесса разработки, уметь их правильно подбирать, организовывать и совершенствовать. ТМ должен давать ответ на любой вопрос дизайнера, верстальщика или программиста по проекту, а также более высоким руководящим должностям, причем в той форме, в которой его руководство способно воспринять и переварить информацию. Быть тем человеком, который ответственен за проект в целом и с которого спрашивают всегда в первую очередь, если что-то идет не так.
Здесь не обсуждается ценность этого работника и оплата его времени, понятно что без него никакого процесса не получится, будут огромнейшие потери времени, то есть понятно, что в данных специалистах существует огромная потребность и естественно их время стоит гораздо больше нежели время конкретного отдельного специалиста.
У читателя, далекого от процесса разработки веб-проектов, может сложиться вот такая коммуникационная картинка:
Здесь дизайнер, верстальщик и программист никак не общаются друг с другом. Все их взаимодействие находится под неусыпным контролем технического менеджера и не дай бог кому-нибудь без его ведома начать вести дискуссию с коллегами по цеху :) Так как мы говорим о веб-студии, в штате которой физически присутствуют все участники данного процесса, такой подход крайне неверен и неэффективен.
Следующее изображение наиболее точно отражает коммуникационный процесс в команде разработчиков:
В команде разработчиков не должно быть никаких ограничений по общению между, как непосредственно самими разработчиками, так и техническим менеджером. Только при такой организации процесса возможна минимизация потерь времени, сил и нервов, если конечно вы не мазохист :)
В этой схеме (рис. 2) не случайно от дизайнера к программисту не идет ни одной стрелки, потому как в реальных условиях в соответствии со спецификой веб-разработки общение этих специалистов почти сведено к нулю.
И тут мы подходим к одной интересной штуке, которая нередко происходит в малочисленных командах разработчиков. В начале статьи я упомянул, что обязанности технического менеджера по причине его физического отсутствия может брать на себя в любом случае кто-то из специалистов. Также из вышеизложенного можно сделать вывод о том, что дизайнер не в состоянии взять на себя подобные, слишком специфичные для него обязанности. Разрыв в понимании того что происходит в специальности друг у друга, у дизайнера и программиста довольно внушительный. Поэтому даже если из схемы убрать технического менеджера, дизайнер и программист все равно будут общаться посредством верстальщика (рис. 3).
В данной схеме (рис. 3), именно верстальщик является «связующим звеном» между всеми участниками, по очень простой причине — в силу своих профессиональных обязанностей. Ведь он, со стороны дизайнера, непосредственно работает с макетом дизайна, общается с дизайнером, дает советы о том, каким образом оптимальное всего изобразить ту или иную графическую часть, чтобы минимизировать трудозатраты на воплощение ее в работающий код, что он сможет, а что в данных условиях невозможно и так далее. Также в обязанности верстальщика может входить интеграция статического HTML-макета в шаблон используемой в проекте CMS, что является довольно распространенной и продуктивной практикой во многих среднего размера веб-студиях. Здесь он непосредственно вынужден общаться с программистом, обговаривая поведение и работу логических элементов проекта, а также устройство и работу элементов шаблона CMS, при непосредственном интегрировании статической верстки в рабочую логику проекта. Хочется отметить, что связка «верстальщик-программист» в отличие от «дизайнер-верстальщик», более всего наполнена разнообразными нюансами и необходимостью в постоянной коммуникации. Поэтому нередко, при определенных неблагоприятных условиях, допускается непосредственное физическое отсутствие в команде дизайнера. Работа с ним может происходить и удаленно.
В редких случаях роль технического менеджера в схеме на рисунке 3 может брать на себя программист, но тогда в силу очевидных причин, все равно ему нужен будет «переводчик» в лице верстальщика для адекватного общения с дизайнером. Это справедливо для ситуации, когда именно все специалисты занимаются непосредственно своей узкой специальностью, если программист попутно занимается версткой, ситуация кардинально может поменяться, и наша схема превратиться в нечто подобное:
Как можно заметить из схемы, программист как бы сам того не понимая берет на себя обязанности технического менеджера. Естественно все это отнимает у него довольно внушительное количество времени. Ведь нужно в своей специальности держать планку, плюс тратить время на совершенствование или хотя бы просто быть на плаву в стремительно текущей и постоянно меняющей русло верстке, плюс еще и руководить процессом разработки. Вдобавок полноценная работа по организации и управлению процесса разработки у него не получается, так как верстальщик стремится внести свои пять копеек, которые по его мнению более весомы, так как он является полноценным специалистом в своем деле, а основная специальность программиста — программирование. Программист, так или иначе, превращается в технического менеджера. Команда все более и более ощущает нехватку времени программиста, открывает вакансию, берет программиста и вуаля, круг замкнулся, смотрим на рисунок 2 :)
Но бывает и немного хуже, программисту может и не понравиться быть техническим менеджером, тогда он, соответственно пожелает уйти из команды, оставив ее без технического менеджера и без программиста. Что представляет собой довольно печальную ситуацию, еще раз доказывающую ценность технического менеджера. Работа по схеме на рисунке 3, в которой временно роль технического менеджера выполняет верстальщик, может просуществовать дольше, нежели по схеме на рисунке 4. Конечно и в этом случае, верстальщику будет постепенно не хватать времени на непосредственное изучение постоянно изменяющейся специальности, плюс ему просто может банально не хватать времени непосредственно на верстку. В этом случае с верстальщиком может произойти тоже, что и с программистом в предыдущей ситуации.
Однако это еще не все. Может случиться так, что никто не захочет брать на себя роль технического менеджера и все будут выполнять только свои прямые обязанности. То есть в коллективе воцарится хаотичный технический менеджмент. В этом случае, если потребуется принять какое-либо управленческое или иное решение в целом по проекту, оно будет приниматься по мере возникновения проблем у конкретного специалиста этим же специалистом, а по этому — максимально субъективно. Причем это решение он будет принимать только исходя из надобности решить проблему в рамках его обязанностей, не оглядываясь на остальных и не представляя, как его решение отразится на конечном продукте, если этот конечный продукт при такой схеме работы вообще получится :) Соответственно при хаотичном техническом менеджменте время, затрачиваемое на разработку увеличивается, мягко говоря, в разы.
Теперь попытаемся представить более целостную схему работы нашей веб-студии с другими абстрактными внешними «управляторами» :) (рис. 5) – Директором и продающим менеджером — тем, кто к примеру встречается с заказчиками (причем нередко вместе с техническим менеджером), отвечает на звонки, ведет отчетность, занимается рекламой, внешними связями и т.д.):
Для удаленной работы со специалистами в студии, по моему скромному мнению, работа должна вестись по следующей схеме:
Здесь от технического менеджера потребуется гораздо больше знаний из различных сфер веб-разработки, так как коммуникация между отдельными специалистами будет сведена к минимуму, который техническому менеджеру предстоит возместить.
Если вы думаете, что ваша веб-студия «прекрасно работает» без технического менеджера, присмотритесь повнимательнее к сотрудникам, возможно вскоре кто-то поймет, что он не в состоянии больше тянуть лямку управленца процессом разработки или выполнять свои непосредственные обязанности специалиста ;)
Очень советую посмотреть занимательную и одновременно забавную лекцию Николая Яремко на тему управления процессом разработки, которая имеется в архиве Я.Субботников — Июль 2010 (Москва) — Роль HTML-верстки в проектировании интерфейсов Яндекс.Почты.