Теперь, когда все имеют общее представление, как вообще можно структурно организовать команду разработки, давайте попробуем разобраться, что из всего этого и в каком виде стоит тянуть к себе, а что нет.
Логическое упущение.
Я не буду говорить про QA и DevOps – не очень умещается в контекст взаимодействия аналитика и разработчика.
Небольшое лирическое отступление.
Жизненный цикл продукта выглядит следующим образом
🔘Разработка – сбор требований, описание бизнес-процессов, проектирование, реализация
🔘Внедрение – установка, настройка, импорт данных, обучение персонала, ввод в эксплуатацию
🔘Развитие – масштабирование, добавление нового функционала
🔘Сопровождение – модификация системы после передачи в эксплуатацию, обусловленная возникающими потребностями или проблемами, проактивная деятельность по мониторингу возникающих угроз, как технических, так и на уровне бизнес-процессов.
🔘Поддержка – реакция на инциденты, выполнение действия по восстановлению работоспособности системы.
Каждый этап требует разного уровня компетенций и динамики взаимодействия. При этом граница между сопровождением и поддержкой достаточно размыта, а внедрение и развитие часто идут параллельно.
Для начала необходимо понять, за счет чего можно достичь главную цель команды разработки – эффективность
👉Гибкость – способность быстро подстраиваться под изменяющиеся условия.
👉Коммуникация – взаимодействие, позволяющее обмениваться знанием, опытом, что приводит к взаимному росту и сокращает время погружения в задачи
👉Ответственность – понимание конечных целей, своей роли в достижении этих целей
Ответственность начинается с головы – поэтому хотя бы в рамках стека разработки (примитивно: 1С, не1С, мобильная разработка) во главе стоит один человек. Его функция – получать ответственность (и пиздюлей) и раздавать её (желательно без пиздюлей). Это на самом деле то, что встречается очень часто.
В рамках одной структурной единицы, подчиненной этому человеку, вполне логично выделение функциональных центров: аналитики и разработки, с собственными тимлидами. Де-факто или де-юре – не принципиально. Главная задача такой позиции – принимать делегирование задач (разгружать босса), манипулировать занятостью сотрудников и прочими ништяками, типа обучения, онбординга и бла-бла-бла.
В зависимости от упоротости компании по проектному управлению, в наличии, кроме аналитиков и разработчиков, могут быть еще и руководители (менеджеры) проектов.
Если РП нет – то с ролью, по сути, владельца продукта отлично справляются аналитики. Причем в более широком понимании продукта как «ценности» - мы можем спуститься до конкретных бизнес-процессов, когда один аналитик полностью погружен в их ограниченное количество, а не пытается залезть во все сразу.
Одна из функций тимлида по функциональному центру – направлять ДОСТАТОЧНЫЕ ресурсы. Не по принципу «год назад Ваня запилил нам охрененную систему, поэтому пусть он добавит в неё 3 строчки кода». А именно выделять того специалиста, чьей квалификации в определенном направлении будет хватать для решения определенной задачи.
При этом мы получаем гибкость – команды не фиксированы. На этапах, требующих большей квалификации и вовлечения, есть возможность увеличивать выделенные ресурсы, в остальных случаях – выделять достаточные. Как только мы забываем о достаточности выделенных ресурсов - не важно, качественно, забивая гвозди молотком, или количественно - фиксируя команду на весь жизненный цикл продукта, вне зависимости от этапа, на котором находится продукт, мы теряем в эффективности.
Финансовая составляющая может внести свои корректировки: если применяется модель финансирования по центрам затрат, то ничего не поделаешь.
Ну и грамотная коммуникация, в рамках текущей серии постов между аналитиком и разработчиком – это и есть итог, который будет в следующем посте.
#медведьразмышляет #управление