Comments 14
2500 человеко-часов в месяц — это команда из 15 человек. Называть такой проект «крупным» — это несколько самоуверенно. :)
Грубо говоря, если всех участников проекта можно собрать в одной комнате, то это маленький проект.
Грубо говоря, если всех участников проекта можно собрать в одной комнате, то это маленький проект.
Возможно вы правы, но всё-таки в рамках заказной веб-разработки в РФ — это достаточно крупный проект в сравнении со «стандартными» заказами веб-студий и digital компаний.
Я даже не уверен, что у каждой студии из топ-10 того же тэглайна вообще есть такие проекты в активной стадии на данный момент.
Я даже не уверен, что у каждой студии из топ-10 того же тэглайна вообще есть такие проекты в активной стадии на данный момент.
Более того в данной серии статей я рассказывал о 2500 человеко-часов в месяц только со стороны веб-продакшена (подрядчика), а не всей команды проекта.
В таких проектах принимает участие огромное количество человек: бизнес подразделения (как правило до 10 — каждый представляет свой продукт), маркетинг, представители IT департамента, управление информационной безопасности, люди из департамента электронной коммерции/digital, а так же другие подрядчики этого клиента. С ними со всеми приходится коммуницировать при разработке таких проектов (об этом я кстати и писал в статье).
В таких проектах принимает участие огромное количество человек: бизнес подразделения (как правило до 10 — каждый представляет свой продукт), маркетинг, представители IT департамента, управление информационной безопасности, люди из департамента электронной коммерции/digital, а так же другие подрядчики этого клиента. С ними со всеми приходится коммуницировать при разработке таких проектов (об этом я кстати и писал в статье).
Очень полезная информация для junior-менеджеров проектов!
Женя спасибо!
Женя спасибо!
Может быть это сугубо субъективное восприятие, но мне кажется рынок средне-больших проектов ещё не готов к тому, что за определенное качество нужно платить. Простой пример — создание большого информативного сайта для средне-крупного банка (без интернет-банка, т.е. без обработки всех платежных операций) было оценено в примерно 1.5 млн рублей. Для данного банка это было уже крупной суммой, начались торги по снижению цены.
Теперь вы говорите, что к вам приходят, недовольные качеством:
>> Многие digital-компании, веб-студии и интеграторы в реальности не готовы к качественному развитию и поддержке действительно крупных проектов. К нам в AGIMA часто обращаются компании, недовольные качеством выполнения работ своим текущим подрядчиком, которого они выбрали на тендере.
Считаем проект продолжительностью в 4 месяца:
PM, TL, PO каждый по 100-150к рублей в месяц
Архитектор, Аналитик, Проектировщик, UX — считаю в среднем по 80к рублей в месяц (пускай мы их подключим на 1 месяц)
4 программиста + верстальщик + дизайнер — считаю в среднем по 80к/месяц
Итого 125*3*4 + 80*4*1 + 80*6*4 = 3 млн 740 т рублей только ваша себестоимость.
Естественно компания с 4-5 сотрудниками не сможет обеспечить такое качество, как при вышеописанном подходе с 20+ сотрудниками и налаженными бизнес-процессами. Но как это понимают клиенты? Вот и получается, что они «обжигаются» на маленьких бюджетах и маленьких компаниях и потом уже сами приходят к тому, что за качество нужно платить.
Теперь вы говорите, что к вам приходят, недовольные качеством:
>> Многие digital-компании, веб-студии и интеграторы в реальности не готовы к качественному развитию и поддержке действительно крупных проектов. К нам в AGIMA часто обращаются компании, недовольные качеством выполнения работ своим текущим подрядчиком, которого они выбрали на тендере.
Считаем проект продолжительностью в 4 месяца:
PM, TL, PO каждый по 100-150к рублей в месяц
Архитектор, Аналитик, Проектировщик, UX — считаю в среднем по 80к рублей в месяц (пускай мы их подключим на 1 месяц)
4 программиста + верстальщик + дизайнер — считаю в среднем по 80к/месяц
Итого 125*3*4 + 80*4*1 + 80*6*4 = 3 млн 740 т рублей только ваша себестоимость.
Естественно компания с 4-5 сотрудниками не сможет обеспечить такое качество, как при вышеописанном подходе с 20+ сотрудниками и налаженными бизнес-процессами. Но как это понимают клиенты? Вот и получается, что они «обжигаются» на маленьких бюджетах и маленьких компаниях и потом уже сами приходят к тому, что за качество нужно платить.
Да, вы полностью правы.
Мы стараемся максимально детализировать все предстоящие работы и прозрачно аргументировать клиенту необходимость каждого этапа, объясняя последствия отказа от определённой роли на проекте. Тот кто уже «обжигался» обычно понимают гораздо быстрее.
Кост мы формируем постепенно исходя из бизнес-задач клиента. Кому-то совершенно не нужны функциональные тесты и мониторинг доступности с системой оповещения, например. А для кого-то это критично и они понимают за что платят.
Т.е. у нас проект обычно стартует как набор небольших заказов, а далее он уже развивается до «гиганта». Самый молодой из «гигантских» проектов у нас сейчас около 2х лет находится в активной стадии поддержки и разработки. Самый старый — уже 6 лет.
Также у нас есть практика, когда мы прописываем определённые KPI в договоре и при их достижении мы получаем прибыль. Клиенты идут на такие договорённости гораздо более смело, но тут необходимо быть уверенным в качестве своих услуг.
Мы стараемся максимально детализировать все предстоящие работы и прозрачно аргументировать клиенту необходимость каждого этапа, объясняя последствия отказа от определённой роли на проекте. Тот кто уже «обжигался» обычно понимают гораздо быстрее.
Кост мы формируем постепенно исходя из бизнес-задач клиента. Кому-то совершенно не нужны функциональные тесты и мониторинг доступности с системой оповещения, например. А для кого-то это критично и они понимают за что платят.
Т.е. у нас проект обычно стартует как набор небольших заказов, а далее он уже развивается до «гиганта». Самый молодой из «гигантских» проектов у нас сейчас около 2х лет находится в активной стадии поддержки и разработки. Самый старый — уже 6 лет.
Также у нас есть практика, когда мы прописываем определённые KPI в договоре и при их достижении мы получаем прибыль. Клиенты идут на такие договорённости гораздо более смело, но тут необходимо быть уверенным в качестве своих услуг.
А потом приходит клиент, и он думает, а какого фига все так криво работает, требует кучу лишних шагов, части функций вообще нет, а та что есть работает странно. Понятно виноват уже заказчик, но пилится же не внутренний портал. Хотя мне кажется, что внутренне ПО вообще страх один.
Не до конца понятно, как происходит взаимодействие PO и заказчика при наличии «первой линии». Это общение происходит через администратора или напрямую?
PO, в рамках конкретной задачи на проекте, начинает общаться с заказчиком напрямую и раньше чем эта задача попадёт к PM'у и первой линии.
Т.е. PO придумывает какую-то классную фичу и обсуждает её с заказчиком, после чего подключает PM'а и всех необходимых специалистов для оценки стоимости и сроков.
Как только заказчик подтверждает необходимость реализации данной задачи, то PO передаёт производство на сторону PM'а и первой линии, а сам только оказывает авторский надзор над продуктом (консультирует внутреннюю команду по задаче, осуществляет приёмку промежуточных результатов внутри, помогает «защищать» эти промежуточные результаты перед заказчиком и т.д.).
Т.е. PO придумывает какую-то классную фичу и обсуждает её с заказчиком, после чего подключает PM'а и всех необходимых специалистов для оценки стоимости и сроков.
Как только заказчик подтверждает необходимость реализации данной задачи, то PO передаёт производство на сторону PM'а и первой линии, а сам только оказывает авторский надзор над продуктом (консультирует внутреннюю команду по задаче, осуществляет приёмку промежуточных результатов внутри, помогает «защищать» эти промежуточные результаты перед заказчиком и т.д.).
Не до конца понятно, как происходит взаимодействие PO и заказчика при наличии «первой линии». Это общение происходит через администратора или напрямую?
Не расскажете поподробнее про внештатных сотрудников? Интересно:
1.Какого рода задачи отдаются на внештатных сотрудников?
2. Есть ли с ними проблемы скорости «вхождения» в проект и как справляетесь (случаи подключения на короткий промежуток).
1.Какого рода задачи отдаются на внештатных сотрудников?
2. Есть ли с ними проблемы скорости «вхождения» в проект и как справляетесь (случаи подключения на короткий промежуток).
Добрый день.
Прошу прощения за долгую реакцию.
1. В основном подключаем на небольшие задачи по разработке. Как правило это могут быть: контентные страницы/блоки, лендинги, формы обратной связи и т.д. Задачи с интеграциями стараемся не отдавать на внешних сотрудников.
Весь код обязательно пристально валидируется: перед работой мы раздаём наши чек-листы, по которым проходит приёмка + проводится код-ревью.
2. Да, проблема не сколько со скоростью вхождения в проект, сколько в целом с уровнем компетенций у внешних сотрудников.
Всегда закладываем дополнительные риски при планировании задачи на аутсорс.
Также делаем детальный тайминг с контрольными точками и стараемся не оставлять внешних сотрудников без присмотра более чем на 16 рабочих часов. Т.е. всегда есть промежуточные срезы.
Вообще относительно нашего взаимодействия с внешними командами/сотрудниками в ближайшие пару недель выйдет моя статья на другом информационном ресурсе. Stay tuned.
Прошу прощения за долгую реакцию.
1. В основном подключаем на небольшие задачи по разработке. Как правило это могут быть: контентные страницы/блоки, лендинги, формы обратной связи и т.д. Задачи с интеграциями стараемся не отдавать на внешних сотрудников.
Весь код обязательно пристально валидируется: перед работой мы раздаём наши чек-листы, по которым проходит приёмка + проводится код-ревью.
2. Да, проблема не сколько со скоростью вхождения в проект, сколько в целом с уровнем компетенций у внешних сотрудников.
Всегда закладываем дополнительные риски при планировании задачи на аутсорс.
Также делаем детальный тайминг с контрольными точками и стараемся не оставлять внешних сотрудников без присмотра более чем на 16 рабочих часов. Т.е. всегда есть промежуточные срезы.
Вообще относительно нашего взаимодействия с внешними командами/сотрудниками в ближайшие пару недель выйдет моя статья на другом информационном ресурсе. Stay tuned.
Sign up to leave a comment.
Как управлять гигантами: правила формирования команды и построения процессов в веб-разработке