Разработка любых продуктов в IT – это сложный, многоэтапный процесс, для четкого выполнения которого требуется грамотное техническое задание. Из-за несвоевременной или некорректной постановки целей и задач любой проект, независимо от уровня сложности, можно сорвать еще на раннем этапе его реализации. В данном материале рассмотрим, какие ошибки чаще всего допускаются на этапе планирования и что можно сделать, чтобы минимизировать потенциальный риск. Вы можете получить требуемые навыки на онлайн курсах project менеджмента по ссылке.
Ошибка №1: частичное изложение задач в такс-менеджере
В компаниях, специализирующихся на разработке софта, обычно используют таск-сервисы наподобие Kaiten или Jira. В них описываются задачи для каждого специалиста в команде.
Один из важнейших инструментов при работе с таск-менеджером – оформление описаний. Ошибка заключается в том, что автор игнорирует такое описание задачи, из-за чего разработчики или другие члены команды не могут четко понять, какой именно результат от них ожидается. Это приводит к тому, что важные для полноценной реализации проекта требования могут быть проигнорированы.
Возможные последствия:
- Дополнительные затраты времени на решение задачи. Если разработчик получит задание без подробного описание, ему придется потратить время на то, чтобы понять, что от него требуется. При этом он может отвлекать от работы своих коллег, из-за чего процесс затягивается еще сильнее.
- Возврат на доработку. Если один разработчик не понимает поставленную задачу – конечный результат не будет соответствовать заявленным требованиям. Вероятнее всего, ему придется переделывать свою работу, тратить время на уточнение, что негативно отразится на продолжительности выполнения всего проекта.
- Готовый проект не соответствует требованиям заказчика. При отсутствии подробных описаний разработчик будет реализовывать те или иные функции так, как он их понимает. Аналогичным образом будут действовать тестировщики, QA-инженеры и другие члены команды. Вероятнее всего, это приведет к тому что готовый продукт не будет соответствовать ожиданиям заказчика. Это повлечет за собой доработку либо потерю ценных клиентов.
Первоочередное решение – донести до команды необходимость четкого описания всех без исключения задач. Это необходимо делать даже если база знаний содержит все необходимые сведения.
При заполнении задания в таск-менеджере обязательно указываются:
- название задачи;
- список требований к производительности и функционалу;
- ссылки на макеты, шаблоны страниц, схемы взаимодействия;
- требования к качеству.
Полный список пунктов варьируется в зависимости от особенностей проекта. Обычно в компаниях используется общий шаблон для описания задач, который утверждают после обсуждения с командой.
Ошибка №2: отсутствует описание предыдущих этапов
Случаи, когда описание предыдущих этапов разработки неполное либо отсутствует, не являются редкостью. Выходит так, что определенные элементы продукта уже готовы, однако требований к их функциональности, производительности и качеству не описаны. Чаще всего такое происходит в командах, в которых отсутствует системный аналитик. Также подобную ошибку допускают в случае, если проект выполняется в спешке.
Из-за отсутствия описания этапов, реализованных ранее, возрастает риск появления регрессионных ошибок. Элементы продукта, которые должны работать исправно, перестают функционировать после доработки и дополнения.
Существует 2 варианта решения:
- Фиксация подробной информации по ранее подготовленным элементам продукта в базе знаний. В случае возникновения ошибок разработчик сможет быстро определить причину и исправить баг, практически не влияя на общий ход работы.
- Создание задач для отдельных модулей. Если они не были оформлены ранее, необходимо сделать это в кратчайшие сроки. Обязательно указываются требования к функциональности, критерии оценки при тестировании, сроки выполнения.
Ошибка №3: одна задача на несколько команд
При внедрении новых функций командам, работающим над backend и frontend могут поставить идентичные задачи. На первый взгляд это кажется оригинальным решением, позволяющим разработать что-то оригинальное и полезное. На деле же такой подход имеет ряд недостатков.
Потенциальные риски следующие:
- Проблемы при определении статуса задачи. Одна команда может справиться с заданием быстрее другой. При этом дальнейшее движение будет приостановлено до тех пор, пока решением задачи занимаются еще и другие специалисты. Это приводит к потерям времени. К тому же управлять таким проектом очень сложно.
- Трудности при тестировании. QA-инженер может неправильно оценивать работу продукта, когда его компоненты находятся на разной стадии готовности. Из-за этого продукт может заполняться багами еще на ранней стадии готовности.
- Плохая детализация задачи. Общее задание для разных команд приводит к тому, что те или иные требования будут игнорироваться. В результате определенные функции будут отсутствовать либо реализуются не в полной мере.
Чтобы исключить потенциальные риски, необходимо формировать так называемый эпик. Это крупная задача для двух или нескольких команд, которую можно разделить на несколько более мелких. Каждая подзадача имеет свое, максимальное детализированное, описание. Это упростит контроль качества и позволит управлять проектом более эффективно.
Ошибка №4: отсутствие аналитики
Не исключаются ситуации, когда новые задачи появляются практически перед самым релизом. Времени на четкое оформление требований нет и команда разработчиков реализуют ту или иную функцию на основе информации, полученной от техлида.
Это приводит к следующим последствиям:
- Лишние траты времени на реализацию. Четкие требования отсутствуют, информация об изменениях не указана. На этапе тестирования специалист не будет иметь представления о внесенных изменениях. Ему придется отвлекать команду разработчиков от текущих задач.
- Неверное представление о продукте. Если требования отсутствуют, разработчик не сможет определить, правильно ли он понял заявленные требования. Из-за этого может пострадать функциональность продукта, что повлечет за собой доработку.
- Ошибки в работе. Из-за отсутствия описания и подробного представления о новом программном компоненте, тестировщик с большой вероятностью упустит баг. Он может проявить себя уже после релиза, повлияв на одну из функций или весь продукт.
Потенциальные риски, связанные с отсутствием аналитики, очевидны. Оптимальное решение – передача задачи аналитику, который осуществит подготовку описания, скорректирует требования и добавит эту информацию на командную платформу.
Ошибка №5: некорректная постановка задачи для аналитика
Задачи для системных аналитиков также могут составляться неправильно. Описание в них может быть неполным либо отсутствовать в целом.
Это приводит к следующим последствиям:
- Неверное определение сроков реализации задачи. Без подробного описания аналитику сложно объективно оценить объем работы. Из-за этого увеличивается время на выполнение ее отдельных пунктов.
- Ошибки интеграции. Без подробной задачи аналитик может упустить требования, связанные с взаимодействием элементов продукта. В конечном итоге это может привести к критическим ошибкам в момент, когда проект уже запущен.
Чтобы минимизировать потенциальный риск, необходимо обеспечить условия, при которых аналитик будет обсуждать задачу с командой. Результаты данного обсуждения должны фиксироваться в описании. Перед отправкой в работе ее следует обсудить и с QA-инженером. Это нужно для того, чтобы его требования были учтены при выполнении.
Ошибка №6: нехватка источников для описания требований в задаче
Системный аналитик может плохо разбираться в специфике того или иного направления бизнеса, из-за чего он не сможет объективно оценивать запросы пользователей и требования заказчика. В результате это приведет к тому, что требования к разработке будут сформулированы некорректно. Это, в свою очередь, негативно отразится на результатах проекта.
Оптимальное решение проблемы – подключение к работе консультанта или эксперта. Это адекватный способ получить подробное представление об определенной нише в бизнесе. Это особенно важно для представителей технических специальностей, которые могут не обладать достаточным количеством информации об особенностях бизнес-процессов.
Также для предотвращения рисков рекомендуется проводить консультационную работу с командой. Специалисты также должны получить подробное представление о направлении бизнеса, в котором потребовались их услуги. Чтобы не консультировать отдельно каждого, можно собрать информацию о проекте и отрасли в базе знаний, заранее согласовав задачи с экспертом и заказчиком.
Заключение
По итогу, можно сделать вывод о том, что подробная проработка описаний позволяет существенно увеличить эффективность работы, сократить время для выполнения задач и минимизировать потенциальные риски. Это важно на любой стадии реализации проекта, как на начальной, так и завершающей. При отсутствии подробных описаний к задачам возрастает риск ошибок, которые могут проявиться на этапе оценки качества или уже после запуска продукта.
К работе над требованиями следует привлекать системного аналитика. Чтобы команда лучше разобралась в специфике проекта, рекомендуется пользоваться услугами консультантов и экспертов.
Источник — агрегатор онлайн курсов
