C'n'C #29 - IT Project Management Ігор Федун - Project Manager в Stfalcon.com - У минулому Project Manager в Four-eyes.io - Знаходжу позитивні моменти в будь-якій ситуації. Люблю відпочинок з друзями на природі

1. Оценка проектов на этапе продажи.
Практические рекомендации и советы.
Взгляд со стороны Project Manager.
Спикер: Игорь Федун

2. О чем мы поговорим?
 1. Основы оценки. Заказчик.
 2. Основы оценки. Исполнитель.
 3. Реальность.
 4. Вопросы. Начало.
 5. Сбор требований.
 6. Бриф с командой по
 оценке.
 7. Оценка проекта.
 8. Учет рисков.
 9. Коммерческое предложение.
0

3. Основы оценки. Заказчик.
 Для чего нужен процесс оценки заказчику?



 Узнать цену проекта Узнать срок реализации Выбрать исполнителя

 Какими переменными оперирует заказчик?




 Бюджет Дата реализации Требования
1

4. Основы оценки. Исполнитель.
 Для чего нужен процесс оценки исполнителю?




 Понять задачу Узнать цели проекта Согласовать ресурсы
 Какими переменными оперирует исполнитель?



 Ресурсы Рейт
2

5. Но есть нюанс!


3

6. Реальность.
 Заказчик:
 1. Хочет получить результат затратив
минимум ресурсов (деньги, время).
 2. Хочет запланировать и зафиксировать
бюджет доступный для создания продукта.
 3. Хочет получить продукт, но не может
объяснить достаточно подробно требования.
 4. В процессе переговоров возникают
вопросы о которых заказчик мог даже не
 задумываться и это меняет его требования
на лету. 4

7. Вопросы. Начало.
 1. Какой бюджет у клиента?
 2. На основе какой информации
был
 сформирован бюджет?
 3. Какой вид оплаты планируется?
(нал/
 безнал)
 4. Какая схема оплаты
планируется?
 (Предоплата, постоплата)
 5. Какие критерии выбора клиент
учитывает
5

8. Сбор требований. Что нам нужно узнать
и выполнить?
 1. Посмотреть входящий email запрос от
клиента.
 2. Выполнить анализ заказчика и человека с
кем происходит непосредственно
 контакт (Linkedin, Facebook, СМИ,
корпоративный сайт).
 3. Получить техническое задание.
 4. Попросить заказчика предварительно
рассказать о проекте, желательно во время
 звонка, голосом.
 5. Попросить заказчика предоставить
черновики (если они существуют).
6

9. Советы.
 Вникайте в детали. Часто небольшая
задача в ТЗ — это огромная работа со
стороны разработчиков.

 Четко определите для себя подход
клиента к выбору технологий и
решений.

 Технические знания очень помогут в
работе, даже небольшие. Общайтесь с
разработчиками. 7

10.  1. Презентовать портрет
проекта
 для команды.
 2. Акцентировать внимание
на
 важных моментах,
которые
 сформировались во
время
 сбора информации.
 3. Выслушать первичное
Бриф с командой по оценке. Основные
задачи.
8

11. Советы.
 Четко донесите цели проекта и
желания клиента. Испорченный
телефон может сыграть с вами злую
шутку.

 Разработчик не всегда выбирает
оптимальное решение, если у вас
есть сомнения, спрашивайте.

 Убедитесь что предлагаемое
решение покрывает основные 9

12. Оценка проекта
 Что необходимо:
 1. Получить ответы на все
 возникшие вопросы.
 2. Разбить проект на
 небольшие задачи и
 провести их оценку.
 3. Оценить сложность задач
 и возможные риски.
 4. Создать документ с общей оценкой
проекта.
 5. Создать блок схему проекта.
 6. Сформировать график выполнения
10

13. Учет рисков.
 Внутренние риски:
 1. Заболел сотрудник.
 2. Неверно рассчитали рабочие дни в
месяце.
 3. Уровень разработчика не позволил
 выполнить задачу в срок.
 4. Неверно рассчитали допустимую
 загруженность сотрудника в неделю.
 5. Неверно оценили задачу.
 6. Неверно оценили время на тестирование
 или bugfix. 11

14. Коммерческое предложение.
 Что должно быть в документе:
 1. Общая информация.
 2. Блок-схема проекта.
 3. Описание предлагаемых ключевых идей
и решений для
 реализации проекта.
 4. Предполагаемый состав команды.
 5. График реализации проекта.
 6. График оплат.
 7. Общая калькуляция.
 12

15. Спасибо за внимание!


 Игорь Федун
 email: igorfiv@gmail.com
 skype: fedunigor