Пять «горячих» кейсов про качество в разработке
Какие проблемы возникают при разработке IT-продуктов, как их решать руководителям и что об этом думают сотрудники? К этому анализу нас подтолкнула реальная ситуация: один из наших frontend-разработчиков поделился опытом «спасения» продукта в команде клиента. Проект он принял у стороннего специалиста. Однако, тот не до конца понял задачу и молчал о проблеме около месяца. «Спасать» проект пришлось уже в сжатые сроки.
Наверняка, подобные ситуации случались в каждой компании, хотя не все готовы делиться такой информацией, даже если она поможет избежать проблем в будущем. Мы в SimbirSoft готовим сотрудников к работе у клиента, сохраняем лучшие практики, анализируем ошибки и недоработки (да, мы тоже не идеальные), а потом делимся этим опытом с коллегами, рассказываем, как грамотно поступать в разных ситуациях. В статье рассматриваем пять частых проблем в разработке и способы их решения, которые могут быть полезны командам, а также руководителям – чтобы вовремя замечать важные признаки в работе с сотрудниками и подрядчиками.
Кейс 1. Молчание о проблемах
Начнем с ситуации, когда у разработчика на проекте происходят какие-то проблемы, а он об этом молчит и никому не рассказывает. Со временем они накапливаются, и процесс выходит из-под контроля. В таком случае предстоит не просто принимать меры оперативного реагирования, а героически спасать ситуацию. Причем такие проблемы могут случиться и тогда, когда процессы отлажены, и с виду все хорошо.
Что по этому поводу думают наши коллеги?
Мне кажется, что многое зависит от команды и, в основном, от ПМа. На моем прошлом проекте была внедрена интересная практика. Раз в две недели мы проводили созвон, на котором наш QA рассказывал о том, что его волнует на проекте с технической точки зрения и не только. Благодаря этим митингам мы смогли добавить много ценных фич. Также был услышан сотрудник, который не хотел отнимать время на ежедневных митингах своими незначительными, как ему казалось, идеями
Как сделать так, чтобы те, кто отмалчивается, говорили о проблемах? На мой взгляд, лучшее решение – проводить мероприятия наподобие ретроспективы с максимально дружелюбной обстановкой, где поощряются разговоры о проблемах и способах их решения. При этом важно опросить каждого участника. После этого озвученные проблемы нужно решить: чем больше, тем лучше. Все должны видеть, что этот инструмент работает
Возможное решение кейса для разработчика
Главное – не молчать, обязательно поделиться возникшими сложностями с командой и руководителем. Как известно, одна голова хорошо, а две – лучше. Это позволит снизить беспокойство и переработки, стабилизировать ситуацию на раннем этапе с помощью более опытных коллег и менеджмента, брейнштормов или корректировки объема спринта. Важно помнить, какая бы сложность ни возникла, ее можно решить совместными усилиями.
В помощь руководителю проекта, тимлиду, владельцу продукта
Как обнаружить такую ситуацию на своем проекте (тревожные сигналы):
- Ни у кого постоянно нет вопросов на ежедневных/общих митингах.
- Хорошо развиты коммуникации между отдельными ролями, но в общем чате всегда тишина.
- Перед релизом часто возникают вопросы, которые можно было решить раньше.
Что делать в этой ситуации? Наиболее популярные методы:
- Формировать культуру свободного, но контролируемого общения.
- Поощрять желание команды говорить о проблемах в начале работы над задачей и предлагать к ним решения.
- Ретро – один из важнейших инструментов. Необходимо сделать его рабочим за счет грамотного ведения, умения разговорить каждого члена команды и соблюдение договоренностей.
- Просить исполнителей своими словами описать, как они поняли ту или иную задачу, чтобы можно было вовремя скорректировать реализацию.
Кейс 2. Поверхностная оценка задачи
Даже опытные разработчики отмечают, что когда смотрят на задачу, им кажется, что она не займет много времени, а когда приступают к непосредственной реализации, понимают, что не всё так просто. Это происходит из-за того, что задача изначально была оценена поверхностно. Ведь часто создание даже обычной формы с двумя полями и кнопкой может потребовать больше времени на разработку, чем кажется на первый взгляд.
Что думают про оценку задач наши коллеги?
При оценке я использую три основных критерия. Первый – выделенные ресурсы на решение задачи: есть ли все доступы, полное ли ТЗ и т.п. Второй – организация труда: приоритет задачи, необходимость коммуникаций в процессе её выполнения, бизнес-процессы и прочее. Третий – объем работ. Потом добавляю еще 30% времени на издержки: срочные созвоны, дополнительные вопросы, «падающие метеориты», попадание в вечное Цукуёми и другое
При оценке новых фич в процессе разработки важно также учитывать время на внесение изменений во всех необходимые части проекта. То есть, перед оценкой нужно проанализировать все места, где могут потребоваться изменения в рамках этой задачи, пообщаться с тимлидом, ПМ или командой, уточнить все места, которые будут затронуты. Иначе можно сделать не все, либо поменять там, где не надо
Возможное решение кейса для разработчика
Для оценки времени на решение задачи необходимо представлять шаги ее реализации. При этом важно помнить, что этот процесс состоит не только из кодинга. Также нужно заложить время на:
- Уточнение деталей, общение с аналитиками и т.д.
- Отладку кода.
- Другие возможные риски.
А если есть неуверенность в оценке, всегда можно прийти и посоветоваться с более опытным специалистом.
В помощь руководителю проекта, тимлиду, владельцу продукта
Как обнаружить такую ситуацию на своем проекте (тревожные сигналы):
- Задача выходит из запланированной оценки, исполнитель передвигает сроки.
- Увеличились коммуникации по задаче у разработчика и аналитика или автора задачи.
- Отмечается более двух возвратов одной задачи с тестирования или приемки автором задачи.
- В более чем 30% задач из бэклога нет описания или оно очень скудное.
Что делать в этой ситуации? Наиболее популярные методы:
- При планировании обсуждать подводные камни задачи и задавать вопросы, все ли понятно при реализации.
- Подготовить шаблон задачи с минимальными сведениями, которые нужно указать в задаче.
- Просить вести обсуждения не устно и в личных переписках, а в задаче.
Кейс 3. Поставленная задача не совсем понятна
Иногда разработчик получает задачу и начинает ее делать, даже если ему до конца не понятно, что конкретно от него требуется. В этот момент он руководствуется логикой, что главное – начать, а разобраться в задаче можно и в процессе. Но в таком случае велика вероятность провести несколько дней над обдумыванием решения поставленной задачи, а потом окажется, что она была понята неверно, и работа проведена впустую.
Как поступают наши коллеги, когда сталкиваются с такой ситуацией?
В этом случае я звоню человеку, который создал задачу. Это решает проблему в большинстве случаев. Либо я понимаю, что он имел в виду, либо он переформулирует задачу
Перед началом разработки, если не все понятно, важно задавать вопросы тем, кто связан с задачей. Попросить провести созвон, если совсем не понятно. Когда возникают трудности при реализации, можно спросить у коллег по проекту или тимлида. Иногда проблемы могут вытекать из-за архитектуры, тогда стоит поднять вопрос по рефакторингу или изменению логики задачи
Возможное решение кейса для разработчика
Если что-то не до конца понятно, лучше спросить у тимлида, аналитика или более опытного коллеги, прояснив все необходимые моменты в самом начале работы.
Важно узнать:
- Какой функционал ожидается после завершения задачи?
- Какие требования предъявляются к окружению (версии браузеров, разрешения экранов)?
- Присутствуют ли все необходимые артефакты (макеты, API и т.д.)?
А также прочитать свежие комментарии к техническому заданию, так как в него могут быть внесены изменения.
В помощь руководителю проекта, тимлиду, владельцу продукта
Как обнаружить такую ситуацию на своем проекте (тревожные сигналы):
- При работе над большой задачей исполнитель первые два-три дня не задает никаких вопросов.
- Отмечаете частые возвраты задач с тестирования/приемки конкретному разработчику.
Что делать в этой ситуации? Наиболее популярные методы:
- При работе над большой задачей в конце первого дня или на второй день уточнить у исполнителя, есть ли сложности и вопросы, как идет процесс выполнения задачи.
- Собирать статистику по исполнителям, у кого чаще возвращаются задачи на тестирование, и давать им обратную связь, вместе разбираться в причинах.
Кейс 4. Критика кода на проекте
Представим ситуацию, когда разработчик недавно зашел на проект, начал погружение и стал жаловаться, что все устроено не так, как он привык, – не тот код, не те правила. На самом деле это не редкий случай. Иногда в начале работы на проекте может появиться желание покритиковать код и существующую архитектуру. Но стоит ли?
Что думают разработчики на этот счет, нужно ли озвучивать свою точку зрения и предпринимать какие-то действия?
Когда представитель клиента спрашивает, есть ли какие-то сложности, я иногда рассказываю про код, который неудобно обслуживать и предлагаю варианты, как поменять. Процессы не ругаю, но стараюсь на них повлиять. Почти везде это приветствуется. Активность одного приводит к комфортной работе всего коллектива. Но нужна воля, чтобы это продвигать
Если желание обосновано тем, что дальнейшая разработка и поддержка проекта будут крайне усложнены, то стоит об этом сказать, обозначив рациональные «за» и «против», и предложить, как можно исправить/улучшить. Но не стоит поднимать эту тему в условиях скорых дедлайнов
Возможное решение кейса для разработчика
Рекомендуем воздерживаться от критики существующего кода и архитектуры в первый месяц работы на проекте. Сначала нужно разобраться, кто принимал участие в разработке и проектировании архитектуры, в подходах к качеству кода и причинах принятия конкретных решений. Затем необходимо сформировать предложения по улучшению и обязательно указать, как это повлияет на продукт, а также обсудить этот вопрос с руководителем проекта.
Так можно внедрять свое видение, пояснив, что это может дать проекту: скорость, надежность и качество.
В помощь руководителю проекта, тимлиду, владельцу продукта
Как обнаружить такую ситуацию на своем проекте (тревожные сигналы):
- Затягивание конкретным разработчиком обсуждений при планировании задач или в рамках ежедневных созвонов.
- Отклонение разработчиком от договоренностей при соблюдении workflow, gitflow и ранее оговоренной реализации задачи.
- Разработчик только критикует и не предлагает мер по улучшению ситуации.
Что делать в этой ситуации? Наиболее популярные методы:
- Давать высказаться, например, на ретро, и просить разработчика предложить решение, как улучшить ситуацию.
- Поощрять конструктивную критику, но и не замалчивать проблемы, у которых нет очевидных решений, а выносить их на обсуждение или делать запрос экспертизы из доступных источников.
- Разъяснить команде, почему сейчас нужно делать именно так, а не иначе, даже если это не самое лучшее решение.
Кейс 5. Долгий поиск решения
Разработчик получил задачу, но не может ее решить. И вроде скиллов ему хватает, но процесс упорно не идет дальше. Знакомо?
Что думают об этом наши коллеги?
В большей степени этот кейс относится к новичкам. На дейли он может говорить: «Да всё понятно, скоро сделаю». Пока напрямую не спросишь, не расскажет о проблеме, а будет копать эту задачу весь вечер и ночь. И есть риск, что такое будет продолжаться на постоянной основе, а через пару месяцев может случиться выгорание. Поэтому не стоит стесняться спрашивать у более опытных коллег. Все когда-то были на вашем месте и прекрасно понимают вас. Существует и противоположный тип новичков, которые пишут своим коллегам о каждой неудаче. Как правило, это люди, которые не хотят глубоко вникать в проблему, они ищут быстрое решение. Если вы замечаете за собой такой подход, рекомендую его пересмотреть, ведь расти специалисту в этом случае приходится долго и тяжело
Хорошо помогают лимиты на «раздумья» – время на поиск решения, если оно не нашлось сразу. После этого нужно признаться, что ничего не вышло, и попросить помощи коллег. Я считаю такой подход верным. Если не получается найти решение за условно короткий срок – спроси товарища
Возможное решение кейса для разработчика
Если по истечении 1/3 времени, выделенного на поиск решения по задаче, у специалиста так и не появились идеи либо просто не получается, рекомендуем поделиться сложностями с коллегами или руководителем. Подготовка сотрудников к непредвиденным ситуациям должна быть обязательной практикой в любой компании, которая ценит время и доверие своих клиентов.
В помощь руководителю проекта, тимлиду, владельцу продукта
Как обнаружить такую ситуацию на своем проекте (тревожные сигналы):
- При работе над большой задачей исполнитель первые два-три дня не задает никаких вопросов.
- Отмечаете затягивание сроков по выполнению задачи.
- Исполнитель уходит от прямого ответа на вопрос о статусе работы над задачей.
Что делать в этой ситуации? Наиболее популярные методы:
- Допустить право на ошибку в команде, но при этом выстроить процессы по оперативному отслеживанию любых проблем.
- Формировать в команде атмосферу открытости, где каждый может высказать свое аргументированное мнение.
- Обговорить с командой рамки допустимого времени на исследование задачи и обозначить, в какой момент стоит просить помощи, если не удается найти решение.
Вместо вывода
Работа на проекте – маленькая жизнь, в которой возникает много сложностей. Компания, оказывающая IT-услуги клиентам, должна готовить к этому своих специалистов. Причем процесс может быть чем-то похож на подготовку к эвакуации в случае пожара: четко прописаны инструкции и правила, все сотрудники с ними ознакомлены, а система отлажена. Мы рассмотрели лишь пять сложностей в плоскости управления людьми, процессами и проектами, но на самом деле их намного больше.
Надеемся, что наши рекомендации помогут руководителям и участникам команд сделать совместную работу еще эффективнее. А какие решения в этом случае могли бы предложить вы?
Если вам нужен сильный партнер в решении ваших проектных задач – до нас всего несколько кликов. Больше кейсов и полезных материалов – в наших каналах:
Буду душнилой сегодня. Вы надоели уже со словом "кейс". Кейс = случай, кейс ≠ что-то еще. Какой-то конкретный пример проблемы, и решить кейс - значит придумать конкретное решение к конкретному проблемному случаю, выход из конкретной ситуации.