Привет. Хотим поделиться с вами своим подходом к разработке. Интересно? Тогда поехали. :)
В первой, вводной, части статьи мы расскажем о самом принципе взаимозаменяемости разработчиков. Во второй поговорим про специализацию и обучение в отделе разработки, а в третьей — про основные плюсы и минусы нашего подхода.
Следите за обновлениями в нашей группе на Facebook. ;)
В чем смысл взаимозаменяемости
О чем речь
Принцип взаимозаменяемости разработчиков — это возможность передать любую из задач проекта любому разработчику. Можно даже в процессе.
Для успешной реализации надо прикинуть внутренние затраты времени на погружение в конкретный проект и код, а также риски простоя и срыва внешних сроков. Сравнив внутренние затраты с внешними рисками, мы находим общий знаменатель с помощью здравого смысла и опыта, и затем принимаем решение: какие задачи кому отдать или передать.
Формирование проектных команд
Принцип взаимозаменяемости разработчиков означает, что несколько разработчиков в разных комбинациях входят в разные проекты.
На каждом проекте команда формируется динамически, то есть состав команд может меняться. При необходимости мы можем добавить разработчиков на конкретный срочный или важный проект. Это заведомо означает, что с других проектов мы их снимаем. Впрочем, не со всех сразу — ведь разработчик никогда не бывает занят чем-то одним.
Бывает даже, что команда проекта меняется полностью. Конечно, такое вряд ли провернешь на проектах с богатой историей, а вот в процессе реализации новых продуктов или фич — вполне.
Скажем по секрету, что и на старых проектах так тоже можно. Все дело в балансе затрат и рисков.
Ключевой разработчик на проекте
Наш подход не исключает наличие основного разработчика на конкретном проекте — того, кто принимает ключевые решения в рамках программного проектирования. Если внимательно присмотреться, ведущий разработчик есть в каждом проекте, просто в нашем случае он может меняться.
В активной фазе реализации определенной функциональности именно ведущий разработчик достаточно сильно погружен в проект, чтобы иметь возможность принимать по нему решения. Если следующий функциональный блок будет сильно отличаться, то ведущий разработчик скорее всего сменится, но это не обязательно.
Принимать оптимальные архитектурные решения и проектировать код на основе поставленной задачи — важное право и обязанность грамотного разработчика. Как бы круто не было сделано проектирование, от этого не уйдешь. И это хорошо.
Мы просто снижаем связанные с такими решениями риски с помощью предварительных бизнес- и технического проектирования, декомпозиции и серии обсуждений.
Управление проектными командами
Проектной командой управляет менеджер проектов с помощью аналитика-проектировщика и технического директора. Обычно аналитик-проектировщик больше всех в курсе деталей и перманентно погружен в свои проекты. Менеджер проектов всегда в курсе происходящего и активно держит связь со всеми причастными к проекту.
Согласованное управление обеспечивает грамотный переход разработчиков между проектами, передачу знаний и постановку задач. Впрочем, сами разработчики уже привыкли и знают, что в любой момент может потребоваться пояснить коллеге тонкости реализации проекта. Ребята уже поднаторели объясняться между собой.
Что подтолкнуло нас к такому подходу и как он развивался
Небольшие проекты, высокая мобильность сроков и простои
Мы начинали свой путь со сравнительно небольших проектов. Задачи порой тасовались, как колода карт. То тут спросили уточнение и надо ждать ответа, то там резко повысился приоритет, а вот здесь наметился отход от запланированных сроков. В результате было очень сложно планировать внутреннюю загрузку разработчиков.
Мы искали выход и нашли его в том числе — но не только! — в повышении собственной гибкости. Так появился принцип взаимозаменяемости разработчиков.
Средние проекты вперемешку с мелкими. Важно выдержать внешние сроки
Мы развивались, как это принято говорить. На самом деле, в какой-то момент мы просто доросли до серьезных, основательных проектов. Нельзя сказать, чтобы там сразу были гигантские бюджеты или много инноваций, но надо было хорошо сделать технически хитрую работу.
Так у нас появились проекты с разными горизонтами планирования. К внутренней гибкости добавилась необходимость строго держать заданные сроки, хотя сроки были очень разные. Модель взаимозаменяемости получила второе серьезное ограничение.
Крупные проекты вперемешку со средними и мелкими
Тем временем, наступил 2019 год. Мы делаем проекты самых разных масштабов, и масштабы эти все растут. Впрочем, от небольших проектов мы тоже не отказываемся, особенно если задача интересная и взаимоотношения с клиентом предполагают перспективу. Нам интересно строить долгосрочные отношения с компаниями-клиентами, потому что внедрение Битрикс24 никогда не происходит быстро.
По-настоящему можно говорить о внедрении Битрикс24 и его успешности где-то через год после ввода в эксплуатацию основной необходимой функциональности. Если функциональность штатная, то год считается от полной настройки. Если были сделаны доработки, то год считается от внедрения рабочей версии доработанной функциональности. Причем надо удостовериться, что внедрение прошло правильно: Битрикс24 осторожно встроился в бизнес-процесс компании, а сотрудники были заранее обучены.
Среднесрочный горизонт планирования и длинный бэклог
Когда планируешь крупный проект, надо знать на старте свои ресурсы хотя бы в среднем горизонте. А чтобы это узнать, надо понимать, сколько и каких ресурсов заберет крупный проект. Получается, что планирование ресурсов зависит от загрузки ресурсов, а загрузка — от планирования. При этом вводные для планирования и для загрузки постоянно меняются.
Таким образом, наша модель взаимозаменяемости разработчиков укусила себя за хвост, как Йормунганд, и замкнулась. Нужно было подобрать ключ к управлению системой с взаимозависимыми неизвестными. Мы нашли свой ключ - это приоритизация.
Так и живем
Приоритизируй
Основное измерение нашей работы прямо сейчас — приоритеты в самом широком смысле этого слова.
Можно сказать, наша модель на основе принципа взаимозаменяемости разработчиков работает как замкнутый контур, в который подается ток в виде задач. А подачей задач, в свою очередь, управляют приоритеты, которые выведены за пределы системы.
Приоритеты задает бизнес, корректирует опыт и новая информация снаружи и извне. Все это меняется без остановки, и мы всегда готовы оптимально реагировать.
Поскольку мы сами управляем приоритетами на основе всей имеющейся информации, мы не скованы обстоятельствами и не воспринимаем изменения в проекте как внештатную ситуацию.
Постановка задачи
Основная задача аналитика-проектировщика и менеджеров проекта — провести клиента от стадии задумки до стадии приемки готового проекта, формируя и оправдывая ожидания всех участников процесса. И разработчиков в том числе — это важно.
Аналитик-проектировщик и менеджер проекта вместе обеспечивают постановку задачи с достаточной конкретикой. Мы стремимся ставить задачи максимально полно, дать разработчику всю необходимую информацию, включая понимание проекта в целом и место задачи в проекте. При этом мы стараемся по максимуму, где это возможно, при постановке задачи не привязываться к конкретным технологиям — языкам, фреймворкам, вариантам реализации.
Дальше мы обязаны ответить на все вопросы разработчика — и вовремя внести изменения, связанные с недостатком информации, в план реализации. Это может быть и лаг ответов от заказчика, и лаг уточнения задачи постановщиком, и лаг в оценке задачи за счет уточнений.
В конце концов, — а на самом деле, в самом начале, — мы должны дать разработчику четкие критерии приёмки. Сейчас мы внедряем приёмку на основе пользовательских историй в дополнение к функциональным описаниям, прототипам, схемам и другим артефактам.
Сбор и тестирование пазлов
Менеджер проекта с помощью аналитика-проектировщика обеспечивает управляемость проекта. Для этого они должны корректно декомпозировать проект, а затем обсудить окончательную декомпозицию и оценку с будущими исполнителями.
В условиях динамического формирования команды мы должны предусмотреть отдельное время на сборку проекта из “пазла” задач разных разработчиков, а также отклонения в оценках разных исполнителей. Для упрощения работы с оценками разных исполнителей мы разработали и сейчас вводим в опытную эксплуатацию стандарт оценки задач.
Особенности декомпозиции учитываются и в работе тестировщика, которого курирует менеджер проекта. Заменяемость разработчиков отчасти, но влияет на тестирование. Есть особенности выполнения задачи конкретным разработчиком, особенности написания кода, а также обстоятельства, которые сопутствовали смене или перераспределению задач.
Спроси разработчика
Мы уделяем все больше внимания погружению разработчиков в проект еще на стадии концепции, то есть на стадии очерчивания бизнес-рамок проекта и наметок реализации. Это повышает вовлечение и личную профессиональную мотивацию разработчиков. Хотя они и не любят такую работу — читать и обсуждать документы, по которым пока не нужно разрабатывать.
Для удобства погружения разработчиков мы приноровились составлять короткие документы, описывающие суть, назначение и технологии проекта. Такие документы могут сильно разниться по формату от проекта к проекту, но предназначение у них одинаковое — служить единой точкой входа для понимания и обсуждения проекта, в том числе для разработчиков.
А еще раннее погружение разработчиков в проект позволяет использовать все мыслимые возможности для упрощения и сокращения грядущей разработки. Что уж греха таить, привлечение разработчиков задолго до собственно стадии разработки существенно ускоряет весь процесс.
Неожиданно, правда? Но ведь это время все равно будет потрачено. Только на принятие решений не до, а посреди процесса разработки — и решения эти будут гораздо более трудными. В разгаре разработки никто не знает, какие ещё временные затраты повлечет за собой любое изменение.
Нам больше нравится тратить это время заранее и сохранять управляемость проектов.
Что мы получаем
Мы уже достаточно давно практикуем именно такой подход и пока не собираемся от него отказываться. Принцип взаимозаменяемости разработчиков дает нам организационную и технологическую гибкость.
Организационная гибкость
Организационная гибкость означает, что у нас нет или почти нет временно непреодолимых внутренних обстоятельств. Всегда или практически всегда можно найти другие выходы. Главное — верно воспользоваться возможностями, которые дает приоритизация.
Вместо того, чтобы искать внешние возможности для маневра, мы имеем для этого внутренние возможности и стимул их использовать. Внешние возможности тоже используем, но точечно и бережно.
Технологическая гибкость
Технологическая гибкость означает, что мы можем выбирать стеки и методологии реализации индивидуально под проект. Мы только отчасти зависим от пула уже реализованных проектов.
Кто-то готов работать по Agile? Отлично, нам это подходит — дает хорошую краткосрочную предсказуемость загрузки и быструю обратную связь от клиента. Кто-то готов только на стандартный водопад, а может, даже только на тендер? Хорошо, мы подготовим схему реализации, которая совместит четкую оценку бюджета с этапностью реализации, гибкостью в возможных пределах и здравым смыслом. В выборе способов реализации наших внутренних проектов мы экспериментируем еще смелее.
Вместо того, чтобы предлагать заказчику свою схему работы, мы готовы подобрать схему работы под каждый отдельный проект или даже под стадию проекта. В пределах нашей специализации на Битрикс24 это не повлечет дополнительных рисков и затрат.
Живой принцип
Разумеется, изменения происходят постоянно. Мы стараемся, чтобы они были конструктивными: следим за внедрением внутренних изменений; убираем то, что не работает; придумываем новые решения назревших проблем.
Наша цель: создавать все условия для нормальной работы хорошего разработчика над реализацией понятной всем задачи с четкими критериями приёмки.
Это реалистичная цель. У нас, в целом, получается. :)
В следующей части читайте о том, как у нас устроена специализация, обучение и взаимопомощь среди разработчиков.
