1. 2. Подготовить описание ролей
1.1. Ввести словарь: Proposals (with types), SOW, MSA
1.2. Подготовить шляпы ролей секции
1.2.1. Менеджер секции
1.2.1.1. Следит за всем
1.2.2. Engagement Manager - Руководитель конкретной оценки от и до (не использовать роль PM, потому что PM ведет проект)
1.2.2.1. Engagement Manager
1.2.2.2. Тот кто делает оценку, и берет проект?
1.2.2.3. Не всегда получается что это один человек, т.к. проект может стартовать с задержкой и PM может быть другой
1.2.2.4. В идеальной ситуации, что бы сэнокомить время на onboarding и избежать проблем передачи знаний, хорошо когда команда оценки PP сама же начинает делать проект
1.2.2.5. Нужно стремиться что бы нормально документировать процесс передачи, тогда не важно кто оценивает и кто будет делать
1.2.3. Технический эксперт привлекаемый к оценке, но не состоящий в Estimates Team
1.2.3.1. Привлекается на оценку подготовленной части
1.2.3.2. Мечтает стать менеджером оценки
1.2.3.3. Подотчетен менеджеру секции
1.3. Статистики позиции
1.3.1. Кол-во оцененный проектов
1.3.2. Количество выигранных PP
1.3.2.1. Conversion Rate
1.4. Описать работу с системами JIRA, SF, Google Drive, PYRUS
1.4.1. в PP никогда не добавляется коммерческое время, всегда создается проект в JIRA
1.4.2. Перенести процесс из JIRA в PYRUS?
1.5. Если не понятен блок в оценке, то описывается как мы это понимаем, как это будет работать и как именно будет реализовано и эстимейт конкретно на нашу реализацию
1.6. Если мы берем тех специалиста не более чем 5 часов в неделю, то для этого не нужно его букать в ресурс плане. Только когда нагрузка становится постоянной каждую неделю больше 5 часов, нужно поднять вопрос о переводе на постоянную работу в Estimates Team
2. 4. Автоматизация (это хорошо, но в первую очередь необходимо прописать алгоритм)
2.1. Форма запроса на оценку
2.1.1. Интеграция с GDrive для развертывания папки внутри Estimates
2.1.2. Интеграция с Jira для развертывания проекта
2.1.3. Уведомление и привлечение участников для оценки
2.1.4. Использовать PYRUS для набора полей из JIRA
2.2. Форма старта проекта
2.2.1. Интеграция с GDrive для развертывания папки проекта
2.2.2. Интеграция с SF для вытягивания данных по клиенту
2.2.3. Интеграция с Jira для развертывания проекта
2.2.4. Интеграция с D3
2.3. Для Sales дать возможность видимо отражать для команды оценщиков причину проигрыша оценки (opportunity in SalesForce)
2.4. Оцифровка основных этапов. Необходима для принятия решения, на каком этапе как именно стоит инвестировать ресурсы. К примеру, если у нас много проектов чисто на Proposal и никуда дальше не идут, нет смысла тратить много времени на первый этап, лучше его потратить на те несколько SOW которые будут одобрены клиентом. Либо же у нас когда у нас большая часть Proposal переходит в SOW, то есть смысл больше вкладываться на этапе Proposal, чтобы минимизировать разницу оценок и больше документировать требования
2.4.1. Трудозатраты на подготовку Proposal
2.4.2. Трудозатраты на подготовку SOW при условии, что проект заходит
2.4.3. Оценка успешности первой итерации, оверхеды при передаче знаний от оценщиков к исполнителям.
2.4.4. После оцифровки принять решение как именно распределять ресурсы.
2.5. Change Log оценок (для передачи клиенту)
2.5.1. Создается единый документ с таблицами оценок
2.5.2. В этом документе как минимум три вкладки: 1. Оценка на Proposal 2. Оценка на SOW 3. Вкладка diff с детализацией изменений, если такие есть
2.5.2.1. Формат: причина изменений - кол-во часов, в каждой срочке
3. 1. Выбрать новое место на орг. структуре для текущих D2.6
3.1. Выбрать департамент
3.1.1. D6 - Оценки это как вводные услуги
3.2. Отредактировать оргсхему
3.2.1. Estimates Team Manager - Dmitry Baklikov Responsible for assigning Estimates Manager - D4. Nik Popok Responsible for assigning Tech Expert - D4. Estimates Manager
3.3. Перенести папки в новую структуру
4. 3. Рост по карьере
4.1. Developer -> PM -> Estimates Manager Estimates Managers TM -> AE
4.1.1. SalesOPS
5. Обработать отзыв о подготовке СОВ на проект HelpMyTask (link)
6. 5.1. Бизнес процесс назначения команды на оценку
6.1. Презентация идет на языке клиента (бизнес или техническом)
6.2. AE находится внутри команды. Ему нужно найти руководителя конкретной оценки.
6.2.1. Пулл людей, разделенных по профилям/экспертизам
6.2.1.1. Этот пулл людей Dedicated или находится в D4?
6.2.2. Руководитель оценки - это специально подготовленный и обученный человек, способный сделать оценку от начала до конца полностью самостоятельно, за исключение привлечения экспертов по технологиям. Конечный результат - Proposal, готовый для презентации клиенту
6.2.2.1. Описать как найти тех эксперта
6.2.2.2. Что делает PM в оценке проекта
6.2.2.2.1. Wireframes
6.2.2.2.2. Состав команды
6.2.2.2.3. gantt/timeline
6.2.2.2.4. описательная часть Proposal
6.2.2.2.5. Выбор типа контракта TM/FP
6.2.2.2.6. Корректировка табилцы с оценки
6.2.2.2.7. Ответственность за консистентность данных в таблице оценки
6.2.2.3. Описать что должен делать руководитель оценки, как идет процесс составления Proposal , как пользоваться инструментами
6.2.2.4. Руководитель оценки должен в полной мере представлять себе как бизнесовую так и техническую часть проекта?
6.2.2.5. CTO проводит ревью всех запросов на оценки и результирующих оценок перед передачей клиенту
6.2.2.5.1. Проверяется схожесть оценок, выявляются паттерны
6.2.2.5.2. Похожие ситуации передаются в RnD для проработки экспертизы
6.2.2.5.3. Во время оценок используется экспертиза D4 по текущим проектам, чтобы уменьшить время на разработку базовых частей, или риски, закладываемые при незнании технологии/доменной области
6.2.2.6. Руководитель перед привлечением технического эксперта делает необходимую декомпозицию и предоставляет тех. эксперту таблицу с оценки
6.2.2.7. Руководитель оценки именно вовлечен в процесс. 2-3 руководителя, доступных на Part-time по ресурс плану, вовлеченных в процесс - то что нам нужно.
6.2.2.7.1. Повысим качество оценки, потому что ее будут делать реально обученные люди.
6.2.2.7.2. Сократится Feedback loop - между 2-3 людьми гораздо проще оттачивать технологию
6.2.3. Руководитель оценки и AE идут на звонок с клиентом для презентации Proposal
6.2.4. Структура передачи запросов: Account Executive -> Est. Team Manager -> Estimates Manager
6.2.4.1. Кто может стать Est. Manager? (PM)
6.2.4.1.1. 20%: EM Делает Оценку -> Передает дальше PM (нежелательно)
6.2.4.1.2. 80%: EM Делает Оценку -> Сам забирает проект (цель)
6.2.4.2. Estimates Team Manager (D6) подает запрос D4 назначить Estimates Manager.
6.2.4.2.1. Определить SLA
6.2.4.2.2. Если D4 не может найти EM, то сам становится EM
6.2.4.2.3. Если D4 не может стать EM, то эскалирует на CTO (либо D4 нет на месте, его замещает CTO)
6.2.4.2.4. Если CTO нет на месте, EM становистя CEO (все согласно орг структуре)
6.2.4.3. Философия мотивации PMам зачем получать шляпу Estimates Manager?
6.2.4.3.1. Это рост по карьерной лестнице
6.2.4.3.2. PM получает базовый фикс в зп (~80%) и возможность до +40% при полной загрузке на проектах
6.2.4.4. Tech Expert - тоже должен быть специально обученный технарь.
6.2.4.4.1. Для него нужна шляпа, которая пойдет сверху Tech Lead
6.3. Переход из Proposal в старт проекта (SOW/Work Order)
6.3.1. PM обязан подчиняться руководителю группы оценщиков
6.3.1.1. Он должен принимать то что ему пришло от оценщиков и исполнять это.
6.3.1.2. В группе оценщиков находятся люди, гораздо опытнее обычных PMов в компании
6.3.1.2.1. Соответственно дисциплина и качество оценок должны быть на высоком уровне, что бы не придраться
6.3.2. Estimates Manager должен улаживать PMa при передаче ему проекта. Ответив на все вопросы, почему проект можно сделать в данный срок
6.3.2.1. При этом PM должен дать свой commitment. Если PM не дает свое подтверждение в чистом виде, что он сможет сделать этот проект в обозначенный бюджет и сроки, то проект не может быть назначен этому PMу
6.3.2.2. При этом, если не один PM не готов взять проект, то следует разобраться в чем дело - или у нас слабые PMы либо не качественная оценка. В таком случае, проект ведет сам оценщик и обязан также сделать проект в срок. ПРи этом решается кадровый вопрос с PMом - замена (когда оценщик докажет что этот проект можно сделать по его оценкам)
6.3.3. Бизнес анализ
6.3.3.1. Проблема при передаче из оценки в разработку
6.3.3.1.1. Часто требования не до конца прояснены
6.3.4. Для подготовки SOW необходимо уже собрать финальную команду
6.3.5. Важно изначальных ответсвенных за оценку назначить на подготовку и проведение первого SOW
6.3.5.1. Когда-то говорили про "Star Team", которая запускает все проекты
6.3.5.2. В этом случае риски несогласованности минимальны
6.3.5.3. Первый месяц как минимум работают с командой, которая стартанула проект
6.3.6. Бывают сложные Pre-sale, на которых проясняется командой масса деталей. Обязательно, чтобы эта команда начала проект т.к. обладает огромным количеством незадокументированных знаний. Возможность задокументировать эти знания весьма сомнительная.
6.3.7. Если проект делает не та команда, которая делала оценку - наше бережливое производство перестает работать
6.4. AE и Руководитель оценки несут ответственность за успешность проекта в будущем
6.4.1. Оцифровка/статистика