Привет! Как и обещал, вторая часть доклада про то, как проводить быстрый аудит разработки без изучения кода (первая тут). Так как весь аудит по своей сути — это качественно поговорить и позадавать нужные вопросы, чтобы потом сделать выводы, то поговорить стоит и про более низкоуровневые вещи, такие как трекер задач, количество багов, метрики, используемые командой, и процесс разработки. В привычном по предыдущей статье формату «Хорошо / Плохо».

Метрики

Количество клиентских багов

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

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

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

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

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

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

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

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

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

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

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

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