Описанные ниже практики могут показаться самими собой разумеющимися для опытных тимлидов и пиэмов, давно и плотно занимающихся профессиональной разработкой ПО. Однако, попав в стартап, можно обнаружить, что горе-фаундеры забыли их внедрить. Давайте о них поговорим.

Гит

На проекте я тимлид,
В мастер пушу свой коммит, 
У меня на это есть
Полный доступ в гит.

Если команда проекта состоит из вас одного, да, можно заливать код по FTP и вносить правки прямо на прод. Но уже когда вас становится двое, начинаются проблемы. Вы будете затирать код друг друга, откат из серверной резервной копии будет занимать массу времени и проч. Кроме того, в процессе залития файлов через FTP, прод будет работать нестабильно. Гит решает все эти проблемы, у вас появляется нормальная версионность, нормальный мерджинг, нормальное залитие кода в прод. Первым делом в стартапе надо внедрить гит, если его ещё не внедрили.

Код ревью

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

CI/CD

Эту загадочную аббревиатуру нужно внедрять в третью очередь, когда гит и код ревью уже заработали. Даёт великое множество профитов — возможность гибко управлять правами доступа, автоматизировать ручные действия и самое главное, возможность нормально масштабироваться. Без CI/CD в случае резкого всплеска нагрузки вам останется только развести руками.

Прозрачный процесс постановки задач

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

В других компаниях руководство грешит тем, что кидается задачами прямо в почте или в чатах, потом удивляется, почему ничего не сделано и ничего невозможно отследить. В четвёртую очередь ставим таск-трекер и принуждаем всех пользоваться им. Если руководство слишком нежное, обязываем кого-нибудь наиболее ответственного из тестирования или, в крайнем случае, тимлида, преобразовывать эти потоки сознания в тикеты.

Руководитель изрыгнул в чат баг или очередную светлую идею — ответственный сотрудник заводит тикет в таск-трекере и скидывает в чат номер. Исключений нет.

Одна задача = одна ветка в гите.

Крупные задачи нужно дробить на мелкие. А для мелких заводить отдельные ветки. Причина проста. Если вы решите вести в одной ветке 10 задач и срочно потребуется релизиться, вы не сможете это сделать, если хотя бы в одной будет критичный баг. Если вести задачи в отдельных ветках, вы совершенно спокойно зальёте 9 рабочих веток с 9 рабочими задачами и обрадуете стейкхолдеров и пользователей.

Автотесты

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

Мониторинг ошибок

Последний, но не по важности пункт, который надо внедрять в стартапе в обязательном порядке. Ставить систему мониторинга ошибок и настраивать этот самый мониторинг. Потому что иначе вы будете узнавать об ошибках от пользователей, как правило, с очень ограниченной информацией, вроде мутного скриншота и ещё более мутного описания последовательности действий. Ещё хуже, если к вам с ошибками будет прибегать кто-нибудь из топ-менеджмента, на этом ваша карьера в этом стартапе может быстро закончиться.

Мониторинг ошибок позволяет узнавать о багах по мере появления, надо только выстроить процесс так, чтобы на этот мониторинг ответственные лица не забивали.

Вот, в целом, и все полезные практики, которые вам нужно завести в свежем стартапе чем раньше, тем лучше.

 
Один из ярчайших русских государственных деятелей, выдающийся политик и администратор Пётр Аркадьевич Столыпин, проводя реформы, придерживался нескольких управленческих принципов.

 
 

№ 1. Проводить преобразования системно

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

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

Системность преобразований нельзя путать с «пилотированием». В ряде случаев имеет смысл обкатать нововведение на фокусной группе и оценить его эффективность.

 
 

№ 2. Начинать с «низовых» потребностей

Пётр Акрадьевич начал систему реформ (имея системный план, конечно) не с провозглашения либеральных свобод, а с самого низа — с обеспечения нормальной жизнедеятельности крестьян и рядовых граждан. Как не может нормально функционировать государство, в котором простое население живёт за чертой, так и не будет эффективной организация, в которой невовремя выплачивается зарплата, возникают перебои с электричеством или теплоснабжением в офисе.

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

 
 

№ 3. Соблюдать стратегические интересы

Придерживаться стратегического плана развития, не упускать из виду основную цель, намного важнее, чем решить сиюминутные задачи.

Например, внедрение очереди запросов — не слишком популярное решение. Заказчики обязательно будут ругаться и давить, потому что надонадонадо срочносрочносрочносрочно. Однако если не организовать очередь, бардак не прекратится никогда.

Что сделать? Небольшую доработку, которая принесёт условные 60 000 руб. через месяц или отрефакторить алгоритм работы с кэшем, что ускорит работу продукта на 15-20 %, но не принесёт прямой прибыли? Если наша цель — качественный продукт, то безусловно, второе. Но лучше бы планировать работы так, чтобы подобных альтернатив не возникало.

 
 

№ 4. Проводить селекцию кадров

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

Нанимаем медленно, увольняем быстро; всегда даём второй шанс, никогда не даём третий; ставим на ключевые посты «умных лентяев».

 
 

№ 5. Добиваться исполнения регламентов

Главной причиной неудач абсолютного большинства реформ Столыпин считал нехватку управленческой воли, которая не дает осуществить запланированное. Порой руководителям кажется, что необходимый эффект достигается уже за счет того, что программный документ напечатан. Столыпин же твердо знал: слово не должно расходиться с делом. Руководитель, не выполнивший запланированное, быстро потеряет авторитет и исчерпает кредит доверия.

Внедрение любого регламента требует времени. Опыт показывает, что обязательно есть несколько человек, хронически неспособных этот регламент соблюдать. Нужно обязательно заморочиться и понять, что им мешает (может быть, регламент нерационален? Может быть, мы его плохо продумали, надо внести правки?) и долбить, долбить, долбить, пока регламент не будет соблюдать весь коллектив.

 

Глубинная причина возникновения дурной бюрократии

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

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

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

Разветвлённая бюрократическая структура стремится к состоянию, при котором все ключевые посты будут заняты сотрудниками, достигшими личного предела некомпетентности.

 
 

Основной признак истого бюрократа.

У такого сотрудника есть несколько характерных черт. Самая яркая — неукротимое желание доказать (в первую очередь, самому себе) собственную нужность. Для этого он генерирует и спускает вниз огромное количество детальных регламентов и инструкций, чтобы создать видимость работы и получить желаемое чувство удовлетворения.

Именно эта особенность бюрократических структур делает их громоздкими, медленными и уязвимыми.

Подробнее о дурной бюрократии читайте в книге «Законы Паркинсона».

Но есть и другая форма бюрократии.

 
 

Правила полезной бюрократии.

Базовое правило: Каждый участник процесса должен точно знать, зачем процесс существует и почему он проводится так, а не иначе.

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

 
 
 

Кейс.

 

Вводная

В организации принят следующий порядок обработки запросов на изменение: регистрация, приоритезация, оценка аналитиком, согласование оценки, написание/корректировка требований, передача в работу, актуализация требований, сдача заказчику.

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

Цель достигнута? Да. Функционал работает так, как надо, правку провели очень быстро (там десяток строк кода, не больше). Всё было бы хорошо, если бы эти два специалиста существовали в вакууме, где кроме них и продукта никого нет.

Затраты — пять минут на разговор, двадцать минут на правку и заливку.

 
 

Последствия.

Спустя восемь месяцев на данный кусок функционала прилетает дефект. Тестировщик анализирует код и отвечает, что это не дефект, всё работает корректно. Менеджер проекта читает документацию по функционалу и понимает, что алгоритм, на который прилетел дефект, не описан в документации. У него на проекте есть кусок кода, который делает непонятно, что.

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

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

Потери на абсолютно бессмысленную работу — около 6 человекочасов всех участников.

 
 

Как надо.

Было бы немножко сложнее. Нужно было создать дефект на требования. Кусок функционала сейчас работает согласно требованиям, но требования неполны, упустили важный алгоритм. Менеджер продукта видит дефект на требования, хватается за голову, правит документацию, создаёт задачу и кидает её разработчику в очередь. Разработчик, когда до задачи доходит очередь, вносит правку, ассоциируя набор изменений с задачей. Тестировщик получает задачу на проверку уже автоматически и проводит проверку. Доработка сдаётся инициатору. Требования полны, в системе существуют явные артефакты корректировки.

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

 
 
Грамотно организованная бюрократия экономит время, предотвращая потери в будущем.