Как ускорить разработку?!

Допустим, вы — владелец небольшого бизнеса. Неайтишного. И у вас есть “маленькая, но своя” команда разработки, которая делает что-то вроде бы полезное. Но так меееедлееенно, что хочется им в башке отверткой что-нибудь подкрутить, чтобы работали лучше. С чего начать? В какую сторону крутить? И поможет ли?

Меня зовут Владимир Завертайлов, я основатель SingularityApp, и уже более 20 лет в заказной разработке в Сибириксе.

На днях сразу двое моих хороших знакомых комерсов пришли с вопросом “Как нам ускорить разработку”. У них небольшие и успешные оффлайн-бизнесы. А ай-ти — что-то вроде второстепенной черной магии. Которая стоит дорого. Работает медленно. И бесконечно бесит.

Чего они уже только не пробовали!

Короче, срочно нужна волшебная таблетка-ускоритель. Причем не важно, как она будет назваться — скрам, канбан, кнут, пряник, кокаин или микросервисы. Главное, чтобы эта загнанная в усмерть лошадь наконец одумалась и начала перформить.

Спойлер: в этой заметке не будет простых и готовых ответов. У меня их нет, я — душнило. Кто тут именно за этим — закрывайте, не тратьте свое время. Будет пара трюков и ссылки на толстые книжки и длинные статьи. Извините, что уже потратили время.

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

Давайте исходить из того, что у вас Хорошие, Адекватные, Мотивированные специалисты. Потому что если у вас плохие, неадекватные и демотивированные специалисты — вы попали по полной. Долбоящеры все портят. Хоть иди-сдавайся на мясокомбинат.

Просто этим Хорошим, Адекватным и Мотивированным специалистам что-то мешает. Чаще всего — вы сами.

Это так, потому что (за оооочень редким исключением) намеренно никто не гадит. Никто намеренно не пишет херовый код. Не рисует херовый дизайн. И не заливает сломанную дрянь в продакшин. Малочисленных упырей, которые гадят намеренно — очень легко и быстро можно вычислить и обвести мелом.

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

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

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

Вопрос “Как ускорить”, на который вы уже много раз пытались найти ответ — это симптом, что что-то уже пошло не так. И, скорее всего, не что-то одно, а прям дофига всего.

Разработка программного обеспечения — это такая штука, которая стоит дорого. И будет стоить только дороже, увы. Мы уже давно не в песочнице. Системы становятся слишком сложными. А сука-энтропия беспощадно делает свое дело, портя со временем то, что казалось-бы сделано хорошо.

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

Я бы вообще начал с вопроса “А оправдана ли своя команда”.

Вот простой способ собрать общий вайб в вашей команде. Сыграем в Digital Boolshit Bingo.

Рисуем на доске колонки “Люди в команде”, “Люди вне команды”, “Процессы”, “Технологии”. И строчки с тремя смайликами. Веселый, нейтральный, грусный. Пусть каждый из вашей команды нарисует палочки в каждой из колонок. Как он это чувствует. Затем вы — нарисуете свои.

Надеюсь, у вас не Единственный и Незаменимый программист, потому что в этом случае становится бздляво. См. Шаг 1.

Далее, что болит — то и решаем. Выясняем детали, устраняем препятствия. Процедуру проводим регулярно.

Постоянные изменения в коде, срочные задачи, костыли — неизбежные спутники современной разработки. Энтропия, которая не щадит ничего.

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

Вам, рано или поздно придётся провести анализ технического долга. Желательно до того, как наступит технический дефолт.

Опять же, нужен кто-то, кто скрупулезно во всём разберется. Проведет code review. Выстроит приоритеты рефакторинга (это когда мы просто причесываем код и делаем его понятным для людей, а не только для машин). Озаботится документацией. Кто-то, кому вы сможете доверять. Где взять — не знаю. Редкость. И на всё это придется выделять время и ресурсы. Чертовски дорогая затея.

Тут главное принять тот факт, что проблема уже свершилась. Нужно ее расхлебывать и сделать так, чтобы она не повторялась.

В проектах, которые развиваются годами, мы в Сибирикс тратим не менее 20% времени на регулярный рефакторинг. Иногда — до 50%, особенно если есть задача высокого покрытия кода автотестами. Зато там почти всё по-полочкам.

Да, какое-то время можно прожить и без хороших привычек. Это как карма. Накопил — получай.

Часто ускорить разработку можно только отказавшись от части функций и хотелок. Всё, что можно не разрабатывать — не разрабатывайте. Возьмите готовые виджеты, закажите на стороне, вообще откажитесь от ненужного.

Мы все галююцинируем по поводу того, какие штуки нужны и важны в проекте. Попробуйте использовать ICE/RICE или другие техники.

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

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

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

Если остались вопросы — пишите в комментарии. Или добавляйтесь в Telegram.