Николай Яремко. Использование вики методик при разработке Яндекс.Почты.
0 likes1,652 views
More Related Content
What's hot (20)
Viewers also liked (19)
Similar to Николай Яремко. Использование вики методик при разработке Яндекс.Почты. (20)
More from Svetlana Gulyaeva (13)
Николай Яремко. Использование вики методик при разработке Яндекс.Почты.
- 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. «Что произойдёт, если нажать на кнопку?»
- 32. Что получилось в Почте? — редизайн и внедрение в 1,5–2,2 раза быстрее (учитывая разные фазы разработки и внедрения) — отчётные презентации проходят в жанре «вы это уже видели, поэтому только важное»; — пожелания от пользователей обрабатываются регулярно; — разработчики делают продукт, а не закрывают отдельные задачи в багтрекере; — понимание продукта не замкнуто в голове «проектировщика». 26
- 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
- 48. 1. Сделайте процесс дизайна наглядным — заведите блог, посвящённый дизайну вашего продукта; — публикуйте в нём макеты, которые объясняют устройство продукта. 42
- 49. 1. Сделайте процесс дизайна наглядным 2. Собирайте новые требования, идеи и пожелания — заведите общее место для сбора вопросов; — публикуйте спорные макеты; — представляйте идеи в графической форме; 43
- 50. 1. Сделайте процесс дизайна наглядным 2. Собирайте новые требования, идеи и пожелания 3. Организуйте обсуждение — на регулярной встрече по разбору вопросов; — не оставляйте комментарии по макетам без ответов. 44
- 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