Fail. Разделение разработки и технической поддержки

Раньше техническая поддержка у нас существовала отдельно от разработки, это были независимые отделы, каждый со своим пулом специалистов. Но здесь была проблема: никто из специалистов не хотел на регулярной основе сидеть на поддержке, все хотели в разработку. Уходя исключительно на support, программисты начинали быстро терять интерес к работе. И это неудивительно: все хотят быть создателями, искать интересные подходы к решению задачи, а не разбирать чужой код, чтобы исправлять закравшиеся ошибки. При таком подходе, как правило, мы получаем демотивированную команду и низкий КПД.

Success. Выделенные команды под проекты

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

Fail. Руководитель отдела не руководит

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

Success. Разделение ответственности и делегация компетенции

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

Fail. Разделение верстки, программирования и администрирования на отделы

Как показывает наша практика, разделение программистов, верстальщиков и системных администраторов на независимые отделы — это нежизнеспособная модель. Классическая ситуация: менеджер проекта просит программиста внести изменения, тот отправляет его к верстальщику. Менеджер приходит к верстальщику, и просит его внести изменения. После выполнения задачи верстальщик рапортует менеджеру, что отправил pull request (что, к слову, для некоторых менеджеров может вообще являться «белым шумом»). Менеджер передает программисту, что результат ему отправили, но программист не понимает, куда отправили: в почте пусто, в скайпе ничего нет, на dev-площадке верстка старая. Тогда программист снова отправляет менеджера к верстальщику, и в итоге процесс хождения менеджера от одного отдела к другому может изрядно затянуться. Конечно, пример утрированный, но общая мысль, думаю, понятна.

Success. Координация работы технического отдела

Мы разработали модель, в которой наши тимлиды являются единым окном для менеджмента. Тимлид координирует работу команды отдела разработки. Если нужно — он сам может подключить верстальщика, системного администратора и других технических специалистов. Он же способен принимать решения и брать на себя ответственность по спорным вопросам.

Fail. Отсутствие стандартов

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

Success. Стандартизация производства

Тогда-то мы и составили наши первые стандарты по программированию и верстке, которые с тех пор активно развиваются и эволюционируют: например, сейчас наши требования к проектам породили целый набор чек-листов, которые мы применяем на всех этапах нашего производства. Все эти вещи позволили нам использовать на наших проектах так называемый «принцип минимального удивления»: от проекту к проекту разработчику, как правило, не приходится тратить много времени на погружение и изучение архитектуры проекта. Новым сотрудникам не приходится долго и мучительно объяснять, как мы привыкли делать: они сразу получают правила, по которым мы разрабатываем свои проекты.

В ходе различных экспериментов мы пришли к формату хранения знаний в своей wiki (мы выбрали продукт atlassian.net). Там у нас хранятся все накопленные данные по проекту: митинг-репорты, данные по архитектуре, регламенты, истории релизов, crash-репорты, правила работы с GIT, если они на этом проекте отличаются от общепринятых в компании, и еще несколько сущностей. Такая база позволила нам проще передавать проект от одного тимлида к другому.

Fail. Каждый отдел в компании сам по себе

Один из больших недочетов — отсутствие коммуникации между отделами вашей компании. Если команда проекта встречается только на этапе продажи проекта — дело плохо. Передача результатов работ по любому этапу должны происходить прозрачно, чтобы все участники понимали, почему было сделано именно так, а не иначе, чем при реализации руководствовался проектировщик/дизайнер/верстальщик. В ином случае на выходе можно получить некоего «франкенштейна», которым не доволен ни один из проработавших на нем специалистов.

Success. Участие во всех этапах

В нашем агентстве мы каждый этап визируем у ответственных лиц: ТЗ обязательно проверяет тимлид, дизайн обязательно проверяет верстальщик; сам же дизайнер осуществляет авторский надзор на протяжении всего проекта. Любой из участников всегда может предложить какие-то усовершенствования, которые мы можем имплементировать в проект. Для некоторых проектов мы устраиваем презентацию этапа для проектной команды. Это позволяет быть уверенными в том, что мы ничего не упустим и не забудем. Кроме того, команда проекта постоянно в курсе его прогресса и такая коммуникация позволяет решать проблемы еще на самых ранних этапах, когда они только зарождаются.

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