Привет, хабраобщество!
Давно не писал материалов, всё больше читал чужие. Но вот, выдалась свободная минутка (пока с трёх iMac’ов сливаются свадебные фото c дисков ввиду отсутствия у моего бука привода :) и я решил выложить материал про наш рабочий процесс. Мы — молодая компания Fruitware из солнечной Молдовы, а я сам совмещаю должности коммерческого и исполнительного директора, хотя наиболее опытен я, как ни странно, в веб-программировании.

Наша компания прошла довольно значительный путь длинной в полтора года от «гаражной» студии из 5ти человек до серьёзной организации из 40.
Я скажу вам честно — увеличиться в 8 раз — это не самый безболезненный процесс и нас не раз лихорадило. Но, учась больше на своих ошибках и немного на чужих, мы построили свой порядок работы, начиная с технического оснащения и до управления проектом.

Redmine

Основной инструмент у нас — Redmine с установленной CRM-системой. Там мы храним проекты и консолидируем информацию о каждом в его Вики. На каждого клиента заведена карточка, на организации — несколько. Каждый новый заказ фиксируется сделкой для работы воронки продаж, а каждый платёж предваряется сгенерированным счётом. Также мы используем вехи Redmine для организации работы по спринтам, в задачах проставляем планируемое время и указываем фактические трудозатраты. Эти же данные используются для проверки работы сотрудников и начисления зарплат и бонусов.

GIT

Весь код мы храним в GIT, выкладываем его на собственный выделенный сервер в Германии (Hertzner). На каждого нашего разработчика открыт отдельный ftp-аккаунт для логирования любых проблем.
Что касается интерфейса управления GIT’ом — в данный момент мы используем gitosys с интерфейсом n98-gitosis-admin, но смотрим в сторону GitLab.

IDE и стандарты

Есть корпоративные стандарты написание кода, корпоративный же IDE (PHP Storm) и набор практик для работы.
По сути это даёт нам нормальную стандартизацию работы, возможность легко подойти к любому разработчику и привычно для себя на его компьютере или ноутбуке внести правки в код, провести код-ревью или помочь с дебаггом.

Штатное расписание

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

1. департамент веб-разработки
2. департамент фронтенд-разработки
3. департамент обеспечения качества
4. департамент мобильной разработки
5. департамент исследований и развития

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

Рабочий процесс

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

Затем по ТЗ составляется два документа — смета со списком больших задач (без ограничений по времени) и список задач с высокой детализацией (не больше 4х часов на задачу).
Конечные исполнители, аккаунт клиента, системный аналитик и главы задействованных департаментов (в том числе и QA) встречаются и обсуждают проект, чтобы все понимали стоящие перед ними задачи одинаково. После встречи уточняется как смета, так и список задач.
Проводится стендап планирования спринта — здесь уже только исполнители, менеджер, тимлид или заменяющий его глава отдела и при необходимости системный аналитик. Затем в редмайне устанавливается веха на первый спринт, определяются конечные проверяемые индикаторы готовности первой версии, они описываются в вики вехи, задачи из списка добавляются в редмайн и назначаются на конкретных исполнителей с ориентировочным сроком выполнения.
Дальше всё по знакомому многим сценарию — дневные стендапы до 15 минут — что делали вчера, что планируете делать сегодня, какие проблемы возникли.
Спринт заканчивается стендапом с обзором сделанного, показом менеджеру получившегося продукта. Глава департамента перед этой встречей делает обязательный код-ревью. Затем, при необходимости, следует ретроспективный взгляд на спринт и обсуждение возникших проблем.
После первого спринта всё повторяется до полной готовности проекта. При необходимости промежуточные результаты показываются клиенту.

Преимущества

1. Мы решаем проблему контроля проекта — возможный срыв сроков — 1 день, максимальный — один этап. Причём оповещение самое раннее.
2. Вся информация хранится в одном месте — redmine. Всегда есть возможность быстро вникнуть в чужой проект или отследить его статус не погружаясь.
3. Все файлы версионируются, опасность перезатереть работы друг друга или потерять какие-то правки стремится к нулю. Отдельные FTP-доступы позволяют увидеть, кто залил некорректные файлы на dev.
4. Мощный сервер позволяет работать с множеством проектов одновременно.
5. Единые инструменты разработки позволяют легко помочь другому, работать в паре или провести code-review.
6. Чёткие зоны ответственности позволяют локализовать проблему, найти того, кто допустил ошибку (а не стрелочника) и предотвратить её повторение.
7. Процесс разработки прозрачен для управленцев и при необходимости может стать прозрачным для клиента.

Будущее

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

1. Внедрение автоматического деплоймента на дев (капистрана или фабрик)
2. Автоматизация процесса создания нового проекта — от создания репозитария по проекту в redmine до закрытия задач через коммиты в гите.
3. Внедрение подробной аналитики с автоматическим рассчётом коэффициентов эффективности конкретного сотрудника и экономической эффективности конкретного проекта.

И многое другое.
Спасибо за внимание, буду рад ответить на ваши вопросы.

P.S. «Почему часть 1?», возможно спросите вы. Потому что, если статья вызовет позитивную реакцию, то я открою карты — поделюсь штатным расписанием, расскажу про настройку редмайна, дам конфиги PHPStorm и многое другое.

Автор: rassol

Источник