- PVSM.RU - https://www.pvsm.ru -
Каждый месяц к нам приходят десятки заявок на разработку электроники. И каждый потенциальный заказчик желает узнать стоимость решения своей проблемы, вне зависимости от того, насколько хорошо он сам её понимает. Может ли контрактный разработчик угодить всем? Как заранее отсеять «бесперспективных»? Как оценить те проекты, которые имеют шансы на развитие? Об этом наша новая статья.
Когда мы только начинали, каждая заявка на почте казалась подарком судьбы. Мы садились всей своей небольшой командой и придумывали, как мы классно реализуем этот проект. Казалось, надо дать каждому потенциальному заказчику максимальную детализацию. Надо выбрать основные технические решения, разбить работу на этапы, вплоть до отдельных задач, нарисовать диаграмму Гантта, просчитать себестоимость изделия и описать всё это как можно подробнее в коммерческом предложении (КП). Мы тратили на каждое КП до нескольких дней, а заказчики уходили на вечное обдумывание.
[1]
Со временем пришло понимание, что можно не тратить попусту время инженеров и отсеивать проекты без будущего ещё до погружения в технические подробности. Прежде всего, необходимо понять серьезность намерений будущего Заказчика. Увы, но запросы вида «я видел вчера в интернете устройство за 50000 рублей, сделайте мне такое же за 30000 рублей» встречаются чаще, чем хотелось бы.
Итак, клиент и проект отвечают всем требованиям, начинаем оценку. Оценка бывает неточной и негодной. Если у нас пока нет ТЗ, мы получаем негодную оценку с большим разбросом. Написали ТЗ – получили неточную оценку. Без ТЗ оценка имеет допуск ±400% и более. Вот это называется конус неопределённости:
[3]
График про интерфейсы, но суть на разных проектах одна и та же. Чем больше мы знаем, тем меньше неопределённость. Не жалейте времени и сил на ТЗ.
Собрания по оценке проектов у нас имеют неофициальное название «Ванга-клуб». Участники заранее знакомятся с материалами по проекту. В назначенный час в Клуб приходят: коммерсант, руководитель проекта, ведущий схемотехник, ведущий программист. Иногда приглашаются дополнительные специалисты с узкой экспертизой, а также представители подрядчиков. Столько людей нужны для всестороннего рассмотрения проекта. Коммерсант рад своей удаче и стремится удовлетворить клиента, упрощая требования. Менеджер проекта должен будет воплотить проект в жизнь, ему отвечать за сроки, стоимость и объём работ. Его стремление – заложить запас, учесть риски. Инженеры хотят делать лучше, чем вчера. Они могут запросто отказаться от простого, но «неинтересного» варианта. Без руководителя проектов можно взять недооцененный заказ, ведь коммерсант бывает очень красноречив. Без коммерсанта можно насчитать так много, что клиент даже не ответит на письмо.
Встреча начинается с общего обсуждения задачи для формирования одинакового понимания всеми участниками. Затем для проекта строится иерархическая структура работ (ИСР, WBS [5]).
Для одинокого устройства выделяются части software и hardware. Для системы добавляются разные части вроде тестового ПО, имитаторов, серверной части и т.д. Полученные части дробятся на части поменьше, например, hardware ветвится на две ревизии PCB и Конструкцию. Следующая стадия – разбить части на отдельные задачи. Если с реализацией всё ясно – задачи должны быть небольшими. Задача «Написать встроенное ПО» категорически не подходит. Нормальными считаем конкретные задачи с небольшими оценками, например: «MCU Драйвер I2C», «Поднять проект», «Схема Э3».
Не стоит оценивать трудоёмкость задач раньше времени, ведь их комплексность и взаимосвязи прояснятся только тогда, когда все они будут записаны на доске.
Всем задачам присваивается трудоёмкость в часах. Метод – экспертная оценка [6]. Часы могут принимать значения из ряда степеней двойки: 2, 4, 8, 16, 32, 64, 128 … Задачи с оценкой 128 часов и более появляются, когда реализация не ясна. Это значит, стоит провести работы по уточнению требований, проверке применимости технологий, а иногда даже просто разойтись и покурить погуглить.
По моим наблюдениям, можно повысить точность оценки, в первую очередь запрашивая мнение менее опытных разработчиков. Так они быстрее учатся оценивать задачи самостоятельно. Если авторитетный инженер уже высказался, все остальные склонны просто согласиться с его мнением. А когда начнутся работы на проекте, задачи, скорее всего, решать будет уже не он, а те, кто промолчал. Их оценку мы всё равно услышим, но не вовремя.
Когда все задачи оценены, мы суммируем результаты и добавляем 30% к ПО на отладку и ещё 30% на тестирование ПО. Эти цифры взяты из статистики по законченным проектам.
В итоге, на доске получается вот такая картина:
Оценка обычно сопровождается увлеченным обсуждением подробностей, ведь вариантов решения задачи может быть много. Так что занимает она никак не меньше часа. Учитывая время на подготовку, даже предварительная оценка проекта может обойтись в 5-20 часов ведущих разработчиков.
Всем нам хочется делать успешные продукты, электронику, которая принесёт пользу людям. Мы обсуждаем, как полученные результаты оценки (сроки, ресурсы) согласуются с задачами проекта в целом. Возможно, стоит предложить клиенту другие пути. Например, урезать функционал для MVP, или взять более дорогое железо в пользу более дешевой разработки. Полезно приблизительно посчитать общую экономику проекта для последующих стадий: постановка на производство, производство, поддержка. Эти цифры показывают относительный вес ресурсов и времени для стадий проекта и могут значительно изменить их восприятие (как наше, так и заказчика).
Полученные от Ванга-клуба оценки мы заносим в Redmine. Для быстрого добавления задач в наглядной форме подходит easyWBS:
Для определения сроков разработки выстраиваем задачи по железу в цепочки (waterfall). Получаем вот такого Гантта:
Для софта мы делим трудоёмкость на производительность того количества людей, которое может быть задействовано в проекте одновременно. Как известно, то, что один программист сделает за месяц, два программиста сделают за два месяца. Так что учитывать весь свой кадровый ресурс при расчёте не стоит. Так же, не в каждом проекте программисты могут начать работы с самого старта. Бывает, нужно дождаться железа, своего или покупного. Такая же задержка может возникнуть на стыке этапов и ревизий железа.
Для информирования заказчика полученные сроки брать нельзя. Разве что с приставкой «оптимистичный прогноз». Лучше дать небольшой запас. Он пригодится.
В модуле Калькуляция проставляются ставки по специалистам и добавляются затраты на соисполнителей, производство, материалы, приборы и т.д.
Прекрасное коммерческое предложение для заказчика.pdf мы создаём прямо отсюда.
Почитайте, как по-разному оценивают проекты наши коллеги на примере одного запроса. Небольшая аналитика двенадцати КП [10].
Итак, проект принят, оценен. Осталось подписать договор – и вперед, переписывать задачи, менять технические решения, расширять требования, меняя проект до неузнаваемости!
Для нас не стоит вопрос, оценивать проекты или нет, ведь мы делаем проекты для клиентов, получить контракт без оценки не получится. Но с внутренними проектами в компаниях ситуация другая. Часто внутренние проекты не оцениваются. И очень зря. Следствие такого подхода – недооценка сроков и ресурсов. Текущий прогресс проекта не может оценить ни команда, ни руководство. Отсюда недопонимание и деморализация команды.
А теперь — айда обсуждать в комментариях ваши подходы к оценке проектов!
Автор: Иван Ларионов
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/350283
Ссылки в тексте:
[1] Image: https://habrastorage.org/webt/qn/bc/u5/qnbcu5wemlywoeqw_i7pl1btte0.png
[2] Image: https://habrastorage.org/webt/bi/wp/ge/biwpgegfrbwwz1idfanbsqjhfrs.jpeg
[3] Image: https://habrastorage.org/webt/uk/c6/gp/ukc6gpflj8l4hxd9dpx2u7ngdby.png
[4] Image: https://habrastorage.org/webt/0k/me/ux/0kmeuxhjjhagt_du7ex07hadlgw.png
[5] ИСР, WBS: https://en.wikipedia.org/wiki/Work_breakdown_structure
[6] экспертная оценка: https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%B5%D1%80%D1%82%D0%BD%D0%BE%D0%B5_%D0%BE%D1%86%D0%B5%D0%BD%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
[7] Image: https://habrastorage.org/webt/au/9g/m9/au9gm9v4c8buoexwpatfdlkzr0w.jpeg
[8] Image: https://habrastorage.org/webt/as/gx/0u/asgx0un5bpgncbcz6wxbysh9a78.png
[9] Image: https://habrastorage.org/webt/rc/zw/rs/rczwrssn0wqvaijyadfvrl97ig4.png
[10] Небольшая аналитика двенадцати КП: https://medium.com/@ioan.larionov/%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D1%80%D0%B5%D0%B7-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D0%BE%D0%B9-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8-%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%B8-%D0%B2-%D1%80%D0%BE%D1%81%D1%81%D0%B8%D0%B8-1d16f8ca1455
[11] Источник: https://habr.com/ru/post/493184/?utm_source=habrahabr&utm_medium=rss&utm_campaign=493184
Нажмите здесь для печати.