Комплексный Workflow. Решение проблем растущей IT-компании. Часть 1

    Привет, хабраобщество!
    Давно не писал материалов, всё больше читал чужие. Но вот, выдалась свободная минутка (пока с трёх 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 и многое другое.
    Поделиться публикацией
    Комментарии 26
      +2
      автоматическим расчётом коэффициентов эффективности конкретного сотрудника

      поделитесь мыслями по этому поводу, очень интересно как кто считает.
        +3
        Сейчас вся аналитика строится на нескольких показателях:
        1. Мы ведём учёт часов, затраченных на каждую задачу
        2. Настаиваем (пока с переменным успехом:) на даче предварительных оценок по задачам в соответсвующем поле в redmine
        3. Имеем вычисленные рейты каждого сотрудника на основе его зарплаты и аммортизированных на всех общих тратах
        4. Имеем рейты с клиентами, зафиксированные в редмайне и бюджет по каждому проекту
        5. В конце месяца начальники отделов по мере сил готовят эффективные часы по каждому сотруднику
        6. Есть бюджеты на отдел и в конце месяца становится понятно, насколько они перекрыты и сколько реальной прибыли принёс, например, отдел дизайна


        На основе этих данных уже можно понять, выгоден ли каждый конкретный проект (даже просто рейт клиента), эффективен ли разработчик, точен ли он в оценках. Конечно по сути сейчас это всего лишь параметры. Подставлять их в формулы (в том числе и зарплатные) приходится вручную. И я вижу массу вариаций автоматического подсчёта, а также внесения новых показателей. Ну и графики всякие наглядные были бы весьма к месту.
          0
          Вот есть сотрудник, по каким-то расчётам и показателям менеджеров, он имеет максимальную полезную отдачу 5 часов в сутки или 2 часа в сутки в режиме «мозгового штурма». Вы его выгоните? Вы думаете можно «выжимать» больше?
            0
            Есть понимание, что хорошая эффективность — это 4 полных рабочих часа из 7 (у нас кстати семичасовой рабочий день, а не восьми).
            Отличная эффективность — 5 рабочих часов из 7. Это не значит, что человек 2 или 3 часа валяет дурака, но очевидно, что есть определённое количество времени, нужное на то, чтобы войти в поток, есть перекуры, походы в туалет, заход на ту же хабру или fb, чтобы немного расслабить мозг. Всё это понятно и совсем не повод для увольнения. Но точно так же довольно очевидно, что отчёты в стиле «я 10 часов искал подходящие картинки для заполнения сайта тестовым контентом» — это не эффективная работа, особенно если на задачу было отведено 2 часа или вообще такой задачи не было в плане.

            Не понимаю, почему хабражители испытывают такую фрустрацию при попытке оценить их эффективность? Ясно же, что строки кода не показатель. Но хороший программист вполне способен оценить как архитектурную реализацию, так и чистоту, понятность, документированность кода. Уж не синдром ли это «вора», на голове которого шапка горит?
        –2
        Суть статьи — «как мы все делаем стандартно». Вот была-бы у вас интересность какая-нибудь, а то коэффициенты на сотрудников, эффективности по строчкам кода да и даже IDE у всех одна — совсем скучно. Зачем разработчиков так контролировать и ограничивать? Дайте им хотя бы инструменты разработки, в которых работать будут только они выбирать им самим.
          +3
          Я до того, как занялся бизнесом успел поработать в двух компаниях и ещё про процессы в добрых 5-6 слышал/видел. Почему-то нигде такого «стандарта» не было. Да и примени мы его год назад — кто знает, не было бы у нас сейчас 120 человек вместо 40.
          Я не в пику тому, что «нифигасебеинновация», но к тому, что не всё на самом деле так очевидно. Многие вещи тестируются до сих пор, какие-то подходы отмирают, другие приживаются.
          Уже сейчас мы склоняемся к уменьшению значения «отработанных» часов в пользу повышения эффективности закрытия задач. Да и те же начальники отделов у нас заполняют только часы по программированию (если оно у них есть).
            0
            Как долго длится у вас проект в среднем? Я о том, что то, что хорошо подходит для коротких и среднесрочных проектов абсолютно не подходит для длительных.
              +1
              По-разному. Есть проекты на неделю, есть такие, которым уже больше года.
              Удобно в общем-то для всех — если разделять вывод задач фильтрами и интерациями. Ну и как раз для долгих проектов с ротацией команды интегрированная вики, вся переписка с клиентами, сделки и инвойсы — очень помогает.
              Есть, конечно, претензии к редмайну. Не всё идеально. Но пока ничего более подходящего нашим нуждам не попалось.
            0
            >эффективности по строчкам кода
            Не надо меня перевирать) Про строчки кода не было ни слова. Эффективность измеряется в часах.
            Несколько человек, сумевшие обосновать необходимость работы в других IDE работают в них. Особенно это касается программистов ранга advanced+ — им-то в редактор никто не полезет, скорее наоборот. Хотя и их мы стараемся склонять всё-таки к PHPStorm. Ибо стандартизация творит чудеса, к тому же для PHP это по моему скромному мнению один из лучших вариантов IDE.
            +4
            Redmine, git, PHPStorm, стендапы планирования, ежедневные стендапы, ретроспективы — что-то мне подсказывает, что такой workflow сейчас практикует чуть ли не половина компаний.

            Еще не понял, как вы так используете git, что вам нужны
            Отдельные FTP-доступы позволяют увидеть, кто залил некорректные файлы на dev
              0
              К сожалению у нас далеко не все используют выкладку на dev-сервер через GIT. Мы довольно активно её внедряем, но людей много и многих надо убеждать, а некоторых обучать (например верстальщиков) — так что процесс идёт не быстро.
              +1
              А что за CRM используется с Redmine?
                +2
                Думаю не ошибусь если скажу, что это Redmine CRM
                  0
                  Благодарю, но я хотел, что бы это сказал автор…
                  Тогда следующими моим вопросами были бы «А рассматривались ли какие-то альтернативы?» и «Какие общие впечатления от Redmine CRM?».
                    +1
                    Семён, подтверждаю. Не хотел давать ссылки, чтобы не сочли за рекламу.
                    Мы пробовали…. Ух. Целую кучу всего.
                    Весной 2012 мы работали с redmine, но нам не хватало CRM-функционала.
                    В мае 2012 мы воспользовались Мегапланом (самым крутым пакетом) — всё, что касается расходов и ЗП было супер, CRM был плюс-минус удобный, трекер задач совершенно неудобный. Именно представление списка — как дерево, так и табличное представление. Ну и цена за систему, которая не удовлетворяла нас на 100% была достаточно большой.
                    Затем мы перешли на planfix — в целом функционал расходов и счетов был понятный, CRM средненький (даже слабый на тот момент), таск-трекинг был неудобный. И самое главное — он жутко тормозил периодически. И иногда даже падал
                    Параллельно мы работали во Wrike (и одного клиента до сих пор ведём там) — самый удобный таск-трекер. Но на единую систему для IT-компании к сожалению не тянет.
                    Следующей системой (примерно сентябрь-октябрь 2012) был www.birdviewprojects.com Им мы пользовались чуть больше месяца. Затем мы окончательно устали, изучили ещё 3-4 системы, смотрели и в сторону saleforce как CRM и на американские системы. В итоге купили плагин CRM, Invoices и вернулись в редмайн. Счастью не было предела) Оказалось, что как таск-трекер он самый-самый, а то, что даёт CRM+Invoices покрывает наши нужды процентов на 70. Аналитика и заплаты остались за бортом, я сам накропал для этого на fuel-php небольшую систему учёта и в общем-то творческий поиск остановился.
                      0
                      Странно, что в этом списке нет Jira.
                        0
                        Сергей, большое спасибо за ссылки на наши плагины. У нас еще много планов на будущее и мы будем стараться покрыть все основные бизнес процессы web-студий и в целом IT компаний небольшого и среднего размера. Скоро можно будет настраивать шаблоны счетов и управлять сметами (estimates). И еще у нас на выходе новый плагин Products который поможет вести учет заказов и продуктов.

                        Кстати, в выходные вышли новые версии для CRM, Invoices и Finance. В CRM добавился новый вид отображения сделок в виде Доски/Pipeline а в Invoices появилось новое состояние Estimate для учета Смет

                        К тому же, мы всегда отрыты для новых идей и с радостью выслушаем предложения и замечания!
                  +1
                  Важный момент. Так и не получил комментариев, нужно ли разворачивать тему дальше. Рассказывать про штатное расписание более подробно, акцентировать внимание на ошибках, которые заставили принять то или иное решение?
                  В общем, если вам это интересно — дайте знать, всё-таки подготовка статьи — не 5 минут времени, хотелось бы заниматься тем, что приносит другим пользу ;)
                    0
                    рассказывайте о штатном расписании и ошибках, конечно же
                      0
                      Расскажите подробнее про то, как именно из гаражной студии вы выросли в 8 раз. Сколько учредителей, как наполнялись кадрами. Действительно, самое интересное осталось за бортом статьи: динамика развития, какая тактика и стратегия развития были выбраны и почему.
                        0
                        Думаю, об этом будет либо следующая, либо 3я часть статьи.

                        Пока же могу сказать, что учредителей двое (я и мой друг), начальный капитал — порядка $2500, первый состав — пять человек (со-учредители и три сотрудника). Динамика роста — примерно по 2-3 человека в месяц. Сейчас стабилизируем бизнес-процессы компании и приостановили рост. Опыта, конечно, за эти полтора года столько, что можно уже книги писать, не то, что статьи :) Какие-то ошибки и решения были хрестоматийными, какие-то — импровизацией и даже местами банальной глупостью, но в целом теперь развиваться куда легче, самый сложный этап уже позади.
                        0
                        Отличная статья!

                        Обящательно нужно продолжать и рассказывать дальше.

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

                        Очень интересует способы расчета зарплаты и учет такой ситуации:
                        «Разработчик сделал задачу быстрее, но потом затратил время на исправление багов». Как вы поступаете в этом случае?
                        +1
                        Рассказывайте, интересный материал. Если поделитесь, как организовываете продажи (план продаж, источники клиентов) и об маркетинговом позиционировании, вообще будет супер :)

                        Дополнительно хотелось бы узнать:
                        1. Redmine Wiki

                        Сейчас тоже пытаюсь ее использовать, но иногда выглядит не очень функциональной/удобной. Возможно, расширяете ее какими-то плагинами или используете особые приемы организации wiki?

                        2. Не задумывались об организации общей базы знаний по компании? Потому что вики по каждому проекту – это одно, но часто есть какие-то общие наработки, внутренние стандарты, это тоже было бы неплохо систематизировать.
                        .
                          0
                          Обязательно расскажу.
                          1. Есть шаблоны, помогающие быстро заполнить Wiki проекта
                          2. Поставили плагин, который создаёт общую базу знаний вне проектов.
                          0
                          Сергей

                          хотелось бы услышать как в вашей компании идет распределение финансов,

                          зп, бонусы руководителей отделов. программистов, прибыль компании

                          чтобы не раскрывать ком тайну (а то вдруг )), можно в процентном соотношении

                          присоединяюсь к dfn «Рассказывайте, интересный материал. Если поделитесь, как организовываете продажи (план продаж, источники клиентов) и об маркетинговом позиционировании, вообще будет супер :)» — очень интересный материал

                          в комментах много хороших вопросов, если большую часть осветить получиться очень хороший кейс по организации работы веб студии
                            0
                            Ребят, много воды утекло, я тут некое «продолжение» накатал, не совсем про воркфлоу, но крылом и по нему, родимому мазнул тоже.

                            Читать тут

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое