Документ обсуждает использование вики-методик в разработке Яндекс.Почты, указывая на важность коллективного понимания продукта и открытости в дизайне. Описаны проблемы, такие как сложность учета требований и споров вокруг дизайнерских решений, а также предложены рекомендации по улучшению процесса. Внедрение вики-методик позволяет ускорить редизайн и повысить качество продукта.

1. Использование вики-
методик при разработке
Яндекс.Почты
Николай Яремко
Екатеринбург, 30 мая 2011 года

2. С чем приходится
жить в разработке
2

3. 1. Нельзя оценить эффект
больших изменений
3

6. ?

7. ?
?

8. 1. Нельзя оценить эффект
больших изменений
Решения принимаются менеджером или командой
разработки продукта исходя из того, как они
понимают, что такое продукт.
Откуда возникает понимание?
7

9. 2. Необходимо учитывать
мнение многих людей
8

10. 9

11. 9

12. 9

13. 9

14. 9

15. 9

16. 2. Необходимо учитывать
мнение многих людей
Все макеты, которые изготавливает дизайнер,
публикуются в специальном блоге, который читает
250 человек.
За время редизайна мы опубликовали
более 200 макетов.
10

18. 3. Сложный продукт требует
детальных спецификаций
12

19. 13 — и это только сообщения об ошибках!

20. 3. Сложный продукт требует
детальных спецификаций
Вместо спецификаций — детальные прототипы и
краткое описание логики работы.
Детализация спецификации происходит уже в
процессе реализации — для понимания она не
нужна.
14

21. 4. Сложно уследить за
множеством новых требований
и пожеланий
15

22. 16

23. 4. Сложно уследить за
множеством новых требований
и пожеланий
Разбор вопросов и пожеланий происходит в
определённое время, сами вопросы накапливаются
в месте, куда каждый может их добавить.
Простые требования встраиваются в текущую работу,
сложные отдаются на проработку дизайнеру.
17

24. 5. Обсуждение и споры вокруг
дизайнерских решений
замедляют процесс внедрения
18

25. 19

27. 5. Обсуждение и споры вокруг
дизайнерских решений
замедляют процесс внедрения
Обсуждения — в клубе и на встречах.
Решения принимает менеджер с помощью
дизайнера.
42% макетов сопровождены HTML-прототипами.
21

28. «Что произойдёт, если нажать на кнопку?»

31. Что получается?
25

32. Что получилось в Почте?
— редизайн и внедрение в 1,5–2,2 раза быстрее
(учитывая разные фазы разработки и внедрения)
— отчётные презентации проходят в жанре
«вы это уже видели, поэтому только важное»;
— пожелания от пользователей обрабатываются
регулярно;
— разработчики делают продукт, а не закрывают
отдельные задачи в багтрекере;
— понимание продукта не замкнуто в голове
«проектировщика».
26

33. Откуда возникает
понимание продукта?
27

34. HUNTING
28

35. 29

36. NT
HU
ING
30

37. HUNTING HUNTING
HUNTING
HUNTING
HUNTING HUNTING
HUNTING
HUNTING HUNTING
HUNTING HUNTING
31

38. Энциклопедия {вашего продукта},
которую пишут все
32

39. Вики-методика помогает
общему пониманию
— Простота — Органичность
— Открытость — Толерантность
— Инкрементальность — Обозримость
33

40. Простота
«Использовать проще, чем ошибиться».
34

41. Открытость
«Любой участник может внести своё понимание
в общую картину».
35

42. Инкрементальность
«Некоторые части продукта могут быть ещё не
проработаны и даже вовсе не придуманы».
36

43. Органичность
«Нет окончательных
решений, логика и внешний
вид интерфейса открыты
для дальнейшего развития».
37

44. Толерантность
«Лучше попытаться и ошибиться, чем ничего не делать».
«Объяснение причины лучше, чем заявление “всё это
никуда не годится”».
38

45. Обозримость
«Любой может увидеть, как идёт работа над дизайном
продукта».
39

46. Коллективная галлюцинация
воплощается в продукте
40

47. С чего начать?
41

48. 1. Сделайте процесс дизайна
наглядным
— заведите блог, посвящённый дизайну вашего
продукта;
— публикуйте в нём макеты, которые объясняют
устройство продукта.
42

49. 1. Сделайте процесс дизайна
наглядным
2. Собирайте новые
требования, идеи и пожелания
— заведите общее место для сбора вопросов;
— публикуйте спорные макеты;
— представляйте идеи в графической форме;
43

50. 1. Сделайте процесс дизайна
наглядным
2. Собирайте новые
требования, идеи и пожелания
3. Организуйте обсуждение
— на регулярной встрече по разбору вопросов;
— не оставляйте комментарии по макетам без
ответов.
44

51. Проблемы
при внедрении
45

52. Как правило, мы не умеем
— организовывать обсуждение;
— сформулировать идею так, чтобы тебя услышали;
— построить прототип, объясняющий устройство
системы.
HU.......NG
46

53. Как правило, мы не умеем
— организовывать обсуждение;
— сформулировать идею так, чтобы тебя услышали;
— построить прототип, объясняющий устройство
системы.
HUNTING
47

54. Николай Яремко
111033, Россия, Москва,
ул. Самокатная, д.1, стр. 21.
+7 (495) 739-00-00
+7 (495) 739-70-70 — факс
nikolay@yandex-team.ru