Юлий Минькин, директор по развитию проектного офиса
Согласно Теории Ограничений нет смысла оптимизировать этапы процесса, которые не являются "узким местом". Вместо этого нужно сосредоточить усилия на обеспечении максимальной производительности ограничивающего фактора - того этапа, который "лимитирует" всю цепочку. Этот принцип в равной степени применим и к этапам проектирования и разработки ПО.
Итак, в разработке ПО могут «лимитировать» весь процесс, как этап проектирования, так и этап программирования/кодирования.
Если разработчики работают медленнее, чем успевает проектировать команда аналитиков, то именно программирование становится «бутылочным горлышком». В этом случае, согласно Теории Ограничений, нужно оптимизировать работу разработчиков. Каким образом?
Первое, что приходит в голову – это нарастить их количество, либо заменить на специалистов с более высокой квалификацией, а если возможно, то автоматизировать рутинные операции разработки кода/тестирования или найти уже готовые решения.
Если же команда программистов справляется быстрее, чем поступают проектные решения от аналитиков, то лимитирующим фактором становится уже проектирование. Значит, именно на аналитиков и следует направить оптимизационные усилия: увеличить штат, найти более квалифицированных сотрудников, внедрить новые инструменты проектирования (СППР) и так далее.
Но очень часто эти меры теряют свою ценность, поскольку, либо недоступны, либо несвоевременны, либо малоэффективны.
Еще одним методом, из арсенала руководителя проекта, может стать вариант, связанный с поиском оптимального уровня детализации проработки требований и проектных решений, в зависимости от того, какой этап в общем процессе является лимитирующим.
Если ограниченным ресурсом выступает группа аналитиков, возможно стоит пересмотреть разделение задач между проектированием и разработкой следующим образом. Например, на первом этапе подготовки и структурирования задач группа аналитики должна ограничиться разработкой базового технического задания, эскизного проекта, без излишней детализации всех модулей. Это позволит быстрее передавать задачи на этап кодирования и разгрузить редких или дорогих аналитиков. Здесь оптимальным подходом видится поиск разумного баланса: достаточной проработки требований для запуска разработки, но без излишней детализации сценариев использования и бизнес-процессов.
Если же узким местом процесса является разработка, то ключевым становится максимально эффективная подготовка и структурирование исходных данных для этого этапа. Например, макетирование интерфейсов, прототипирование бизнес-логики, сегментирование требований. Это позволит снизить нагрузку на этап разработки и ускорить работу программистов. При этом важно понимать потребности разработчиков и готовить для них именно такой объем информации, который будет полезен. Излишняя детализация на стадии анализа так же вредна, как и недостаток информации.
При таком подходе важно найти своего рода разумный «компромисс» между глубиной проработки и оперативностью подготовки заданий. И его можно выработать в результате тесного взаимодействия аналитиков и разработчиков.
Если рассматривать IT-проект с позиций Теории Ограничений, мы приходим к выводу о важной роли этапа анализа требований и проектирования в повышении эффективности всего процесса разработки. В сочетании с другими методами, руководитель проекта может найти разумный уровень детализации заданий, чтобы добиться оптимизации всей цепочки процесса разработки ПО.
Если материал понравился — ставьте палец вверхи подписывайтесь на канал, чтобы не пропустить другой интересный и полезный контент 👍
Контакты:
Адрес для связи по вопросам прохождения курсов, стажировки или трудоустройства: ProIT@1cbit.ru 📬
Вы можете написать нам по любым вопросам, мы обязательно ответим и будем рады оказать вам помощь и содействие! 🤝
Вам также могут быть интересны другие наши статьи: