Привет! Как и обещал, вторая часть доклада про то, как проводить быстрый аудит разработки без изучения кода (первая тут). Так как весь аудит по своей сути — это качественно поговорить и позадавать нужные вопросы, чтобы потом сделать выводы, то поговорить стоит и про более низкоуровневые вещи, такие как трекер задач, количество багов, метрики, используемые командой, и процесс разработки. В привычном по предыдущей статье формату «Хорошо / Плохо».
Метрики
Количество клиентских багов
Помните фильмы, где главный герой лежит в больнице, подключенный к кардиомонитору, и там на экранчике бежит график сердцебиений? Когда график вытягивается в прямую линию, значит, всё грустно и главный герой умер.
Так вот, с клиентскими багами такая же история. Это пульс продукта. Если в метриках их ноль — то это самое страшное. Это значит, что продукт или вообще не используется, или что клиенты никогда не запускали его.
Нет, конечно, есть исключения, когда какой-то продукт присутствует в компании чисто для галочки. Такое может попадаться в сфере информационной безопасности — например, клиент с точки зрения закона обязан купить какое-то ПО, но никто не будет проверять, используется этот софт на самом деле или нет. Скажем, купила компания антивирус, чтобы соответствовать требованиям регулятора, и просто положила его на полку — aka «бумажная безопасность». При таком подходе вообще без разницы, что там делает разработка — можно ее хоть уволить всю. Захочется ли вам работать в такой компании — это уже отдельный вопрос.
Итак, отсутствие багов — это плохо. Хорошо — это когда они есть, причем динамика изменений может быть любой, главное, чтобы это имело под собой какое-то логическое объяснение.
Допустим, кривая багов резко пошла вверх — такое может объясняться тем, что компания быстро выпустила на рынок новый продукт с довольно сырым функционалом. Я, к слову, знаю одну подобную компанию — у них на самом деле много багов, но они сразу договорились между тремя подразделениями (разработка, продакты и поддержка), что вполне осознанно выходят на рынок с сыроватым продуктом и готовы огребать от пользователей. Зато всё работает и процесс пошёл, потому что в качестве альтернативы у них была вторая версия: годик подождать с выпуском, допилить продукт до идеала, всё отлаживать и в процессе благополучно упустить рынок.
А вот если график ведет себя странно, и люди не понимают, почему так происходит — это плохо.
Что в этом разделе ещё важно — обычно в любом трекере есть названия модулей и компонентов. Обращайте внимание на распределение багов по ним, так можно понять, где находится какое-то узкое место, которое следует изучить внимательнее.
План на разработку
Ещё важно узнать, на какое время у компании есть план на разработку. Понятно, что сейчас мир такой, что всё быстро меняется, и, если есть стратегия на ближайшие год–два и понимание, куда вообще идти — это хорошо.
Это ситуация, к которой в целом стоит стремиться.
Существуют две обратные ситуации:
планов нет вообще, и непонятно, чем именно планирует заниматься компания
план на два года (или лет на 5) такой, что там успели продать огромное количество обещаний с конкретными датами и фичами-монстрами в нём.
О чём вам говорит вторая ситуация? О том, что, скорее всего, в этой компании сроки стабильно не выполняются, и с этим вам придётся бороться.
Пример. Приходим к владельцу одного бизнеса, и видим у него на столе большой бумажный документ, прошитый нитками — план разработки на два года, с точными сроками и подписями всех C-level. Это значит, что план не выполняется хронически, а сроки едут всегда. Такие документы с подписями — это просто откровенный крик души в надежде, что хотя бы высокоранговые подписи как-то изменят ситуацию и помогут.
Спойлер — не помогут, план не выполнится. Тут всё понятно, в целом, и дальше можно даже ничего не смотреть.
Взаимодействие с клиентами
При изучении этого параметра смотрите на то, как оно выстроено и есть ли какие-то метрики. Метрики могут быть любые — NPS, CSAT и другие.
Главное, чтобы они вообще были. Потому что если нет никаких метрик, то с большой долей вероятности самой серьезной проблемой в компании считают проблему самого шумного клиента. Например, есть какой-то один клиент, который всегда громче всех — и именно его проблемы будут считаться самыми важными, даже если клиентов тысячи, просто остальные тише.
Кроме отсутствия метрик, очень плохи ещё две вещи. Первая — отсутствие процедуры обработки жалоб клиентов. Вторая (и еще неизвестно, что хуже) — когда все желания клиента сразу ставятся в план. Это плохо, так как не все эти хотелки могут укладываться в уже имеющуюся логику развития продукта. В итоге получится откровенно жуткая архитектура на костылях и велосипедах с квадратными колесами, которая пытается куда-то ехать.
Компания должна уметь отказывать клиенту.
Вот вам пример — мы разрабатываем продукт, который мониторит информационные потоки компании, в том числе и почту, то есть почта так или иначе проходит через нас, идёт её анализ, какие-то кусочки складываются в базу и прочее. Клиент просит нас заодно сделать и бэкап почты: «Ведь вы же её всё равно всю видите». На что мы ему говорим, что не будем делать бэкап почты, потому что это не наш бизнес.
Подобное следование любым желаниям клиента могут маскировать обтекаемыми фразами вида «Мы очень клиентоориентированные», «мы стараемся выполнять все пожелания» — это всё очень нехороший сигнал.
Оценка задач
Очень важно понимать, кто оценивает задачи. Если это коллектив авторов, то есть команда, которая и занята разработкой приложения, это хорошо.
А вот если один человек (каким бы умным он ни был), это плохо. Потому что он в любом случае не сможет учесть всего, у него есть какой-то свой бэкграунд — разработка, тестирование, аналитика, из-за чего он будет фокусироваться по большей части на своей области и не сможет учесть всех возможных рисков.
Так что, если вы увидите, что задачи оценивает один человек, можете быть практически уверенными — сроки тут поедут. А это всегда сказывается на качестве, потому что когда едут сроки, то чаще всего срезают тестирование.
Как построена работа
Хорошо, если перед вами кросс-функциональные команды, которые делают функционал полностью под ключ.
Плохо — ситуация с перекидыванием тикетов через забор. Когда одна команда что-то запрограммировала, а затем перекинула тикет в jira в соседнюю команду потестировать. Это первый признак того, что сроки будут активно ехать, и вам придется с этим работать.
Только в диаграмме Ганта получается, что после окончания одного прямоугольничка разработки сразу плавно идёт следующий. Реальность же такова, что между этими этапами всегда есть некий лаг — кто-то может быть занят, кто-то не сразу подключится. В итоге в момент, когда тестирование закончится и баги полетят назад, по ту сторону уже могут забыть, что вообще делали.
Получится, как в миниатюре Райкина — вроде и пуговицы к костюму пришиты хорошо, карман отличный, а пиджак всё равно криво сидит.
Что спрашивать про метрики
Первое — просто спросите, какие метрики вообще есть. Второе — почему они важны.
Здесь важно понять, почему люди вообще используют конкретные метрики. Иногда бывают метрики ради метрик, карго-культ. Скажем, SLA по багам — модная штука, у всех есть, давайте измерять. А потом смотрите эту метрику и видите, что она вся красная: баги хронически не правятся. Возникает логичный вопрос — зачем тогда мерить всё это, если баги не правят?
Если метрика не используется и люди не понимают, зачем она вообще им нужна — это плохо. Выходит, что люди не понимают, что делают, а просто тратят ресурсы на подсчет ненужных цифр.
Вот хороший пример — команда решила повысить качество продукта за счёт покрытия кода юнит-тестами. Стали мерить покрытие юнит-тестами и подняли их число с 0% до 80% в каждом модуле. Даже если не оценивать это с точки зрения «хорошо это или плохо» — здесь хотя бы понятно, что люди понимают, что они делают и зачем.
Может оказаться, что в компании используются странные метрики, например, измеряют количество строчек кода, написанного разработчиком. Как так получилось? Попался CEO, который решил, что это как-то показывает производительность. Согласно городским легендам, именно так получился тот самый индусский код, когда кто-то додумался платить программистам за строчки кода.
Заметить такое, на самом деле, полезно — вы сразу для себя поймёте, по пути ли вам с таким CEO и хотите ли вы с ним работать.
Что мы вынесли из второй части статьи
Нужно изучить
качество планов
коммуникацию с клиентами
организацию команд
метрики
баги
состояние трекера
Отдельно про трекер — тоже постарайтесь оценить для себя: трекер для команды это реальный рабочий инструмент или очередной карго-культ? Пользуются они им, или просто заводят туда задачки время от времени?
Например, если много непонятных статусов, если есть исправленные баги, на которых не стоит resolved, это всё плохо.
И вишенка — если у вас хватило времени и вам дали такую возможноcть, вы добрались до практик разработки.
Инженерные практики
Смотрите на то, что используется в командах. Вот список того, на что я обращаю внимание — если что-то из этого есть, то есть и надежда, что исходный код у ребят хорошего качества. Ваш список может быть другим, дополняйте в комментариях.
Некоторые практики де-факто можно считать бизнес-фичами, взять даже SDLC. Если говорить про инфобез, в котором я работаю 11 лет, очень важным моментом является получение сертификата ФСТЭК. Тут ничего особенного — статанлиз, файзинг, обновление сторонних библиотек. То есть сертификация не требует ничего необычного.
Но если всего этого у вас нет, а бизнес-плане есть этап с получением сертификата ФСТЭК через три месяца или через полгода — то всё, вы не успели. Совсем. Вы вряд успеете сделать всё это.
Как понять, что практики реально работают
Если есть автоматическая составляющая контроля практик, например, человек физически не может что-то закоммитить, пока коллега не отжал галочку code review — то коммит не проходит, тесты падают. В таком случае можно хотя бы надеяться, что практики работают.
А вот если практики вроде как есть, но бездушная машина их не контролирует — скорее всего, они не работают.
Оцениваем качество продуктов
Это можно сделать, даже не запуская сам продукт. Просто спросите, пишут ли программисты тесты сами (это хороший симптом). А второй вопрос — как люди относятся к тестированию.
Если по ответам поймёте, что к тестировщикам относятся не очень уважительно и в формате вида «есть у нас пара девочек-тестировщиц, смотрят там что-то» — это плохо.
Тестирование должно жить с разработкой на одном уровне и взаимоуважительно.
И не забывайте задавать вопросы про инфраструктуру. Возможно, проблемы компании не в том, что автотестов нет, а в том, что сначала надо будет закупить железо, чтобы эти автотесты вообще было где запускать.
Резюме двух статей
Описанные методики позволят вам провести быстрый аудит компании, в которой работают 100–200 разработчиков. Само собой, при аудите условного Яндекса это будет выглядеть немного иначе.
Правильное использование советов из обеих статей поможет вам получить некий диагноз, который подсветит проблемные места. Вы будете знать, что вас ждёт при выходе на новую работу или же при покупке какого-то бизнеса.
Более того, по сути это всё анализ не просто разработки, а всего производственного цикла в компании, который начинается с первого контакта с клиентом (сейл или продакт) и проходит до создания продукта и его выхода в эксплуатацию. Таким образом анализируется весь бизнес-процесс.
Спасибо, что дочитали, если у вас есть вопросы или уточнения — пишите в комментариях, постараюсь ответить