Третье занятие в рамках курса "Управление Web-проектом" в Технопарке@Mail.ru: https://tech-mail.ru/

1. Управление Web-проектом
Занятие №3
Правила разработки

2. План занятия
 Кому и зачем эти правила?
 Трэкер как инструмент разработки
 Планирование и приоритеты
 Контроль и тестирование
 Документирование разработки
 Примеры реальных правил
2

3. Кому и зачем эти правила?
Зачем?
 Отсутствие хаоса
 Минимизация ошибок
 Ускорение выполнения задач
3

4. Кому и зачем эти правила?
Какими они должны быть?
 Простые
 Понятные
 Очевидные
4

5. Кому и зачем эти правила?
Виды правил
 Спустили сверху
 От более опытных коллег
 Собственный опыт
5

6. Кому и зачем эти правила?
6
Откуда они берутся ?

7. Кому и зачем эти правила?
Базовые принципы
 Не навреди!
 Лучшее – враг хорошего!
 Оптимизируй разработку через правила!
 Правила могут устаревать!
 Не будь заложником правил!
7

8. Кому и зачем эти правила?
Собственные правила – лучшие правила
 Повышаем ответственность
 Повышаем вовлеченность
 Гарантируем дальнейшую работу по ним
8

9. Кому и зачем эти правила?
Итог
 Ускоряет разработку
 Уменьшает стресс разработчика
 Дисциплинирует
9

10. Трэкер как инструмент разработки
Наш инструмент для игры по правилам
 Единый
 Удобный
 Разрабатываемый под наши нужды
10

11. Трэкер как инструмент разработки
Основные типы задач
 Код
 Арт
 Концепт
 Описание
11

12. Трэкер как инструмент разработки
Основные статусы задач
 Новая
 Текущая
 На одобрении
12

13. Трэкер как инструмент разработки
Тайм-менеджмент
 Контроль общей загруженности отдела
 Фактическое время на конкретную задачу
 Текущая задача сотрудника
13

14. Трэкер как инструмент разработки
Роли в Трэкере
 Заказчик
 Исполнитель
 Глава отдела
 Инициатор
14

15. Трэкер как инструмент разработки
Комментарии
 Описание найденных ошибок
 Дополнение содержимого задачи
 Отчетность по задаче
15

16. Трэкер как инструмент разработки
Итоги
 Выбирайте инструмент под ваши нужды
 Работайте в нём по правилам
 Пишите отчеты по задаче в комментариях
16

17. Контроль и тестирование
Контроль
 До распределения
 После выполнения на тесте
 После выполнения на релизе
 После выполнения на бою
17

18. Контроль и тестирование
Проверка на тестовом сервере
 Работоспособность самой задачи
 Проверка исполнителем
 Проверка заказчиком
 Безопасно на 100%
18

19. Контроль и тестирование
Проверка на релизном сервере
 Работоспособность задачи с «боевым контентом»
 Проверка исполнителем на боевых значениях
 Проверка заказчиком на боевых значениях
19

20. Контроль и тестирование
Проверка на боевом сервере
 Задачу видят конечные пользователи
 Боевая нагрузка
 Ловим уникальные для сервера ошибки
20

21. Контроль и тестирование
Итог
 Контролируем перед началом работы
 Тестируем в несколько этапов
 Каждый этап тестирования уменьшает % ошибок
21

22. Планирование и приоритеты
Виды планов
 Годичные
 Месячные
 Недельные
22

23. Планирование и приоритеты
Планы на год
 Крупные запуски
 Никаких деталей
 Выполнение KPI проекта
23

24. Планирование и приоритеты
Планы на месяц
 Состоят из крупных задач
 Средняя детализация
 Ответственные за запуски крупных задач
24

25. Планирование и приоритеты
Планы на неделю
 Конкретные небольшие задачи
 Максимальная детализация
 Взаимодействие «заказчик-исполнитель»
25

26. Планирование и приоритеты
Из планов катализируются приоритеты
 Приоритеты внутри проекта
 Приоритеты между проектами
 Система работает только, если все проекты за ней
следят
26

27. Планирование и приоритеты
Приоритеты внутри проекта
 Хот-фиксы неотложные
 Праздничные патчи
 Ближайший патч
 Обычные задачи
 Много типов приоритетов = хаос
27

28. Планирование и приоритеты
Принципы приоритетов
 Небольшое количество
 Универсальность
 Простые формулировки
28

29. Планирование и приоритеты
Приоритеты между проектами
 У каждого проекта есть свой приоритет
 Внутри проекта есть приоритеты
 Отлично, когда у приоритетов единый шаблон
29

30. Планирование и приоритеты
Итог
 Градация планов: от крупных к мелким
 Проектные и межпроектные по единым правилам
 Приоритеты: понятные, универсальные, немного
30

31. Документирование разработки
Плюсы
 Упрощает взаимодействие специалистов
 Наглядно
 Дисциплинирует
31

32. Документирование разработки
Минусы
 Надо этим кому-то заниматься
 Требует постоянной поддержки
 Площадка может быть неудобной
32

33. Документирование разработки
Ряд правил
 Документировать должен тот, кто полностью
разбирается
 Документирование должно быть удобным
 Легкий доступ всем, кому необходимо
33

34. Документирование разработки
Что документировать?
 Правила написания кода на проекте
 Описание значений
 Правила работы с админкой
34

35. Документирование разработки
Итог
 Документирование избавляет от проблем
 Документирование тратит время
 Документируйте разные сферы
35

36. Примеры правил
Меняем старое только при острой необходимости
Примеры острых необходимостей:
 Невозможно поддерживать
 Невозможны доработки
 Невозможно масштабировать
36

37. Примеры правил
Непонятна задача – задай вопрос
 Лучше потратить время до начала
 Задающий вопрос всегда молодец
 Плохо сделать неправильно
37

38. Примеры правил
Если аналогичную задачу кто-то делал – узнай у него
 Ускоряем время выполнения задачи
 Получаем опыт
 Избегаем тривиальных ошибок
38

39. Примеры правил
Несколько похожих задач – уточняем приоритет
 Максимальный фокус на нужды проекта
 Вам не всё равно
 Лучше уточнить, чем решить самому
39

40. Примеры правил
Уточняем формат результатов задач
 Приходится переделывать
 Едут сроки
 Нервничают заказчики
40

41. Общий итог
 Ведите документацию!
 Соблюдайте правила!
 Используйте удобные инструменты!
 Планируйте и расставляйте приоритеты!
 Формируйте правила после ошибок!
41

42. Контрольное занятие
Формат
 Представление своего проекта
 Ответы на вопросы по проекту
 Презентация проекта + успешные ответы на
вопросы – 20 баллов
 Домашние задания без выступления – 10 баллов
 Презентация проекта+домашние задания – 30
баллов
42

43. Вопросы?
 Спасибо
 До новых встреч!
43