Документ описывает процесс управления и разработки highload-проекта, включая различные стадии, требования к задачам, корректировку календарного плана и составление сметы. Подчеркиваются ключевые особенности highload-проектов, риски, изменения в бизнес-процессах и необходимость привлечения высококвалифицированных специалистов. Также представлены важные аспекты оценки ресурсов и подготовки документации для разработки.

1. Менеджмент и бизнес-
процессы в разработке
highload-проекта
Олег Бунин
oleg.bunin@ontico.ru

2. К нам пришёл
заказчик!

3. Первая версия процесса

4. Стадия №1
Подготовим описание
задачи

5. Результат стадии №4
Матрица задачи -> часы
специалистов разных
специальностей

6. Первая версия процесса

7. Вторая версия процесса

8. Стадия №3
Декомпозиция на
задачи

9. Требования к описаниям задач:
1. Задачи атомарны;
2. Чем меньше по объёму – тем лучше (< 1 дня);
3. Грамотный русский язык;
4. Запрещается копипастить из скайпа;
5. Дизайн-макеты, скриншоты – всё для фронта;
6. Задача не меняется со временем;
7. Запрещено использовать кванторы всеобщности,
типа “заменить на всех страницах”;
8. Все устные обсуждения фиксируются в описании;
9. Запрещено ставить подзадачи в комментариях.

10. Результат стадии №3
Сформирован список
задач

11. Вторая версия процесса

12. Третья версия процесса

13. Стадия №5
Корректировка
результата

14. Разработчики всегда
ошибаются!

15. Разные коэффициенты
для разных
специальностей

16. Разные коэффициенты
для разных классов
задач (обычные и
инфраструктурные)

17. Результат стадии №5
Реальный объём
проекта

18. Третья версия процесса

19. Но объём проекта не
равен календарному
плану!

20. Четвёртая версия процесса

21. Стадия №6
Формирование
календарного плана

22. Что важно учитывать:
1. Взаимосвязи между разработчиками;
2. Взаимосвязи между задачами;
3. Атомарность этапов;
4. Управление процессом:
- время на SCRUM;
- время на планёрки;
- время на ретроспективы.
До 20% уходит на планирование!

23. Нужно ли учитывать тот
факт, что эффективное
время работы менее 8
часов в сутки?

24. Проверьте, не забыли ли:
1. Время на регрессионное тестирование перед сдачей этапов;
2. Время на деплои этапов;
3. Известные (и неизвестные отпуска);
4. Буферное время между этапами;
5. Время на технический долг;
6. Праздники и отходняк;
7. Текучка кадров, время на поиск и обучение сотрудников;
8. Корпоративные мероприятия, выезды для объединения
команды и поднятия боевого духа;
9. Время на обработку изменений (не реализацию, а
обработку);
10. Поиск и вовлечение подрядчиков.
PS: Даже если у вас Agile и горизонт планирование в две
недели вы всё равно могли это забыть 

25. Результат стадии №6
Диаграмма Ганта

26. Добавляем
аналитиков и
менеджеров
(как целое, 67% менеджера не
бывает)

27. Результат стадии №6
Диаграмма Ганта с
менеджерами

28. Стадия №7
Составляем смету

29. Мы переводим календарный план, в
котором учтено всё, в смету.
Умножаем месяцы из календарного
плана на ставки специалистов.

30. Поздравляю!
Вы получили
себестоимость
проекта.

31. Четвёртая версия процесса

32. Эй! Уважаемый!
А где highload?

33. В чём технические
отличия обычного
проекта от highload-
проекта?

34. В простом проекте
данные хранятся так,
как их удобно хранить.

35. В highload-проекте
данные хранятся так, как
их удобно выводить.

36. Возникающие
особенности и риски

37. 1.
Нарушается логическая
связь между простотой
элемента и простотой его
реализации

38. 2.
Программисты чаще
ошибаются в расчёте
требуемых ресурсов

39. 4 изменения в бизнес-
процессы

40. 1.
Для точной оценки требуемых
ресурсов потребуется привлекать
высококвалифицированных
технических специалистов для
разработки технического дизайна.

41. 2.
К разработке технического дизайна
допускается только полностью
описанный эпик.

42. В описании эпика должна
содержаться вся необходимая
информация:
1. Верхнеуровневое описание;
2. Детальное описание бизнес-логики;
3. Дизайн-макеты;
4. Ссылки на страницы в прототипе;
5. Критерии приёмки для тестирования;
6. Ответы на потенциальные вопросы;
7. Описание перспектив развития функционала;
8. Нетехнические требования.

43. Это не совсем
техническое задание –
это документ, удобный
для разработки

44. 3.
К оценке добавляется целый ряд
инфраструктурых задач.

45. Добавьте инфраструктурные задачи:
1. Нагрузочное тестирование;
2. Пуско-наладочные работы;
3. Разработка JS-машины;
4. Кроссбраузерность (и мобильные браузеры);
5. Мультиязычность;
6. Тестирование безопасности;
7. Отказоустойчивость;
8. Миграция данных;

46. Проверьте, не забыли ли highload-задачи:
1. Заложено ли время на сборку страниц?
2. Разработка заглушек для SOA;
3. Время на проектирование API;
4. Согласование взаимодействие между серверными и клиентскими
разработчиками;
5. Code review – в крупном проекте тимлид будет занят только им;
6. Разработка документации для редакторов, коммуникация
специалистов с заказчиком;
7. Время на изучение новых технологий;
8. Юнит-тесты;
9. Время на изготовление рыб (изображений, текстов, объектов) для
демонстрации;
10. Аналитические работы;
11. Время на технический дизайн;
12. Обновление и модификацию технического задания.

47. Пятая версия процесса
Готовим описание
проекта / фичи /
итерации
Проектирование
технического
дизайна

48. 4.
Компетенций менеджера
недостаточно – разработчиками
управляет тимлид.

49. Сессия вопросов и ответов
Как организован
сам процесс
разработки?

50. Напиши на oleg.bunin@ontico.ru
и получи три документа
1. Структурирование и использование JIRA;
2. Инструкция по подготовке эпиков;
3. Правила написания технического дизайна.

51. Олег Бунин
oleg.bunin@ontico.ru
http://highload.ru/
http://highload.guide/