И сразу отвечу на вопрос, зачем это вообще может понадобиться. 

Есть четыре типовых ситуации:

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

2. Участие в due diligence. Ваша компания планирует покупку стороннего бизнеса. Тут аудит нужен для того, чтобы не повестись сходу на красивые продающие слова и не купить кота в мешке. С большой вероятностью, техническая сторона при объединении бизнесов может оказаться в вашей зоне ответственности, и нужно понимать, чем это грозит.

3. У вас попросили консультацию — на профессиональной основе или в формате помощи другу.

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

В этой статье я расскажу, как адекватно и полноценно оценить состояние разработки. Меня зовут Андрей Бирюков, в разработке я 25 лет — начинал как разработчик, сейчас руковожу разработкой и клиентскими сервисами в InfoWatch. С этой темой я выступал на CTO conf, теперь подготовил для вас текстовую версию.

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

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

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

Поймал мужик золотую рыбку, а она ему говорит:

— Отпусти меня, что хочешь сделаю!

Мужик отвечает:

— Хочу стать Героем Советского Союза!

И остался мужик с двумя гранатами против пяти танков.

Что и с чем сравниваем

Есть некий идеал разработки, к которому (с моей точки зрения) нужно стремиться, вы для оценки можете использовать свой собственный — сферическая компания, в которой всё здорово и процессы разработки выстроены так, как вы считаете правильным. Она и будет точкой отсчёта. И при сравнении других компаний с ней нужно смотреть, насколько далеко они находятся от идеальной, по каким именно критериям всё совсем плохо, по каким — близко к идеалу, что надо поправить, какой можно составить список проблем.

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

Так что проблемы точно есть.

Как выявлять и фиксировать проблемы

Говорить с людьми. Задавать разные вопросы разным людям, смотреть на ответы, сравнивать их и выявлять проблемные места.

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

Критерии сравнения

Из основных аспектов я выделяю.

Бирюзовость компании

Это четвёртый уровень корпоративной культуры, если вы читали, например, «Лидер и племя». Суть в том, что компания и все её работники внутри дружно сражаются против окружения — или против конкурентов, или против агрессивных условий внешней среды. Иными словами, работают вместе и слаженно, что требует хорошо выстроенной коммуникации как между отделами, так и между командами.

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

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

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

Многие, к слову, иногда просто говорят, что у них аджайл. Приходишь к ним и спрашиваешь, мол, как у вас устроено? Отвечают — всё здорово, у нас позадачный скрам по спринтам на два года вперед, мы его чётко придерживаемся и никогда не меняем.

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

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

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

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

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

Общая схема аудита

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

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

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

Давайте пошагово.

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

Это или прямой владелец бизнеса, или CEO. Просим его рассказать про продукт, как он его видит, какие у него ожидания как от продукта, так и от вашей с ним встречи. Ведь если разговор вообще происходит, значит, ему от вас что-то надо. Обсудите проблемы.

Здесь такое же ветвление, как и в ситуациях с вашим трудоустройством или покупкой бизнеса.

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

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

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

2. Говорим с Product Manager

Обсуждаем планы развития продуктов и насущные проблемы. Уточняем, что они думают про разработку, какие видят в ней сложности. 

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

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

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

Вот чеклист для общения с продактом.

Мелко порезанный функционал важен — это значит, что история разработки с большой долей вероятности управляема. А вот если там гигантские фичи, скажем, «Надо сделать текстовый редактор», то это звоночек. Представляете, сколько усилий и денег надо на создание аналога Word?

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

3. Говорим с вашими потенциальными подчинёнными

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

Есть три схемы попадания планов в разработку.

1. Прилетает ТЗ, все просто начинают его делать

Мы как-то общались с одной компанией, у которой именно так всё и было. Просто прилетало ТЗ, люди его делали и отправляли дальше по конвейеру. А потом на вопрос «Кстати, вы вообще знаете, что происходит с тем, что вы запрограммировали?» получали ответ «Нет, не знаем, оттуда нет никакого фидбека». 

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

2. Прилетает ТЗ, его хорошо объясняют, есть общение с продактами

Эта ситуация сильно лучше, потому что правильный продакт в состоянии донести до разработки много полезного и нужного, а не просто формальное ТЗ.

3. План разрабатывается совместно

Как по мне — лучшая из альтернатив.

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

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

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

4. Изучите команду

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

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

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

Оцените готовность выйти за формальную зону ответственности, например: Вопрос: «Как у вас с наймом?».

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

Хороший ответ: «Резюме от отдела кадров были так себе, мы обсудили с ними, поменяли вместе ключевые слова для поиска и описания для hh, стало сильно лучше».

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

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

Есть такой не самый хороший симптом, когда руководитель команды (особенно большой команды) — это самый лучший технарь, который программирует и тестирует куда круче, чем все остальные. Это значит, что команда у него слабая, а он — не самый хороший руководитель. И из-за того, что он такой умный, с ним ничего нельзя сделать. Наши западные партнёры используют для этого термин «job security» — когда человек замкнул на себя все, и его нельзя уволить.

Вот только он сам при этом не справляется. И это проблема.

5. Поговорите с поддержкой

Это люди, которые напрямую взаимодействуют с клиентами, использующими продукт.

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

Сравниваем полученные ответы

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

А вот если поддержка открыто жалуется на производительность, а продакты вообще не в курсе — это уже плохой симптом.

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

Вот чем мы закончили первую часть статьи (да, будет вторая).

• теперь мы понимаем бизнес-цели

• продуктовые планы

• выявили проблемы коммуникации

• определили, куда смотреть дальше

А дальше смотреть мы будем в трекер задач и подробно изучать процесс разработки.

О чём я и расскажу во второй части статьи.

Спасибо, что дочитали, буду рад вашим комментариям и вопросам.