1. Ошибки аналитика.
Общие ошибки аналитиков, работающих в ИТ-индустрии.

2. О чем будет эта презентация
 Ошибки в нашей жизни
 Анализ в ИТ. Этапы
 Этап 1. Знакомство
 Этап 2. Сбор требований
 Этап 3. Анализ
 Вместо заключения. Правила
Аналитика.

3. Опыт в нашей жизни
Опыт - это то, что мы получаем, когда не
получаем желаемого.

4. Ошибки в нашей жизни.
 Подумайте - сколько времени мы тратим на оценку
успешных действий, а сколько - на оценку неудач?
 Время и силы на "разбор полетов" отличаются
кардинально (разница обычно от порядка и выше).
 Оценка причин достижения успеха могла бы дать
очень много, однако, на деле она почти не
производится - такова особенность человеческой
психологии (успех воспринимается как само собой
разумеющееся).

5. Ошибки в нашей жизни.
 Первая и общая наша ошибка – это не уделение
анализу причин успеха должного внимания.
 Успех не воспроизводим сам по себе.
Игнорирование этого приводит к тому, что
авторы и лидеры успешных проектов становятся
могильщиками в других.

6. Этапы работы аналитика
Меняются технологии, этапы - остаются.

7. Этапы работы аналитика
 Вне зависимости от используемого способа
ведения работы над проектом, работа
аналитика всегда будет включать три
следующих этапа:
 Формирование первичного образа решения
 Работа с материалами и заказчиком
 Анализ и фиксация требований
 Второй и третий этапы могут итеративно
повторяться в течении жизненного цикла, но
они всегда будут выделяемы.

8. Знакомство
Первое впечатление - всегда самое важное и
устойчивое. Как при общении с людьми, так
и при знакомстве с задачей.

9. Знакомство.
Ошибки
 Каждый раз, когда начинается проект - звучат
слова «новое и уникальное», тем самым
порождаются ложные и вредные
представления.
 Создаются излишне тяжелые, морально
устаревшие еще до своего рождения проекты.
 Не уделяется достаточно внимания первичному
анализу слабых мест решения

10. Знакомство.
 Этап знакомства с задачей – наверное, самый
важный.
 Образ решения формируется почти мгновенно,
а для его изменения потом - требуется масса
сил и времени.
 Используйте чужой и свой опыт! Что бы было,
если бы архитекторы проектировали дома, не
считаясь с тысячелетним опытом своих коллег?

11. Знакомство
Велосипед
 Не изобретайте велосипед - берите идею
готового, ищите аналог, выделяйте ключевые
свойства (то, что делает велосипед велосипедом
- не больше).
 Даже очень богатые люди покупают серийные
автомобили (что бы не говорила реклама) -
пусть и "собранные вручную».

12. Знакомство
Пингвины - не летают. Что бы вам не показывали
по телевизору:)
 Многие программные комплексы, внешне
похожие на птиц - на самом деле пингвины,
которым постоянно требуется пинок (или
катапульта) для продолжения их полета.
 Оставьте в ядре системы только минимум -
легкий каркас. В противном случае – стоимость
и сроки реализации решения увеличиваются на
«вес» катапульты.

13. Знакомство
Будущее
 На этапе постановки целей проекты часто
ориентируются на "сейчас" (или того хуже -
"вчера").
 Сравнение с конкурентами - это прекрасно, но -
помните - вы сравниваете свои "завтрашние"
возможности со "вчерашними" возможностями
конкурентов. Выход один – анализ трендов.

14. Знакомство
Слабые места
 Воспользуйтесь опытом архитекторов -
начинайте работу с поиска видимых слабых
мест. Сделайте их сильными местами вашего
решения.

15. Знакомство
Болезни роста
 Задача часто решается "в лоб", в отрыве от
контекста и перспективы. Результат - получаем
перегруженный уродливыми ящиками и
скрипящий от собственной тяжести комод.
 Если нельзя переформулировать и обобщить
задачу до ее совпадения с уже имеющейся
архитектурой - нужно или отказаться или
строить новое решение (кто знает - возможно -
пришло время реинжиниринга).

16. Сбор требований
Сбор требований это итеративный диалоговый
процесс.
Аналитики не обучаются ведению переговоров.

17. Сбор требований
Ошибки
 Не умение и не понимание того, как и зачем
проводятся переговоры, с кем и о чем надо
говорить, что должно быть результатом.

18. Сбор требований
Переговоры
 Переговоры - это то, что делает аналитика
аналитиком, как минимум на 30%.
 К любой встрече с заказчиком надо готовиться -
как это происходит на обычных переговорах.

19. Сбор требований
Персона
 Говорят не с тем, кто решает, а с теми, кто
соглашается говорить. Разговаривая с таким
человеком - вы скорее всего просто даром теряете
время. И его и свое.
Требования авторов проекта
 Действительные требования авторов проекта (или
иначе - требования бизнеса) остаются за кадром.
 Решается не та задача, для которой был
инициирован проект, а та, которая была озвучена
аналитику.

20. Сбор требований
Общий язык
 Проект строительства вавилонской башни
провалился из-за языковых проблем.
 Разные среда и задачи порождают разные
оценки одних и тех же ситуаций. (Стакан на
половину полон или он на половину пуст?)
 Люди мыслят шаблонами 85% времени и
принимают решения в условиях ограниченной
рациональности (а не абсолютной)

21. Сбор требований
Искусство говорить «НЕТ»
 Принято считать, что "клиент всегда прав" - но, в
данном случае, это не так.
 Вас приглашают не для того, что бы вы просто
соглашались с тем, что вам говорят. Для этого
есть другие люди и другие места.

22. Анализ требований
Помните – «важно все» это на самом деле –
«все неважно».

23. Анализ
Ошибки
 Слишком много требований ("все важно")
 Не правильный выбор факторов риска.
 «Стенографические" требования.
 Аналитик не может увидеть ситуацию глазами
бизнеса

24. Анализ
Презумпция виновности
 Требование лишнее, если оно не признано нами
как ключевое и заказчик не может доказать его
важность и значимость для решения. Если по
его мнению оно ключевое - пусть он обоснует и
докажет это.

25. Анализ
Принцип 20/80
 Сокращать число требований. Для этого
используем правило Парето (20/80)
 Привлекаем mindmap и ТРИЗ.

26. Анализ
От общего к частному, от частного к общему
 Частные требования надо обобщить, общие -
сделать более частными. Граница схождения
этих двух процессов - верифицируемые
высокоуровневые требования.
 Помним о полноте. Возможно, после доработки,
полученную картину придется дополнять - и
идти собирать требования снова.

27. Анализ
Стакан - он на половину полон или пуст?
 Задача системы - поддерживать бизнес, а не
менять его в угоду разработчику и мифической
"оптимизации бизнес-процессов".
 Аналитик и бизнесмен в обычной жизни видят
мир по-разному. И предпринимают разные
действия. Аналитик должен уметь видеть мир и
думать как бизнесмен.

28. Анализ
Риски
 Сейчас ситуация такова, что основной риск -
время (изменения происходят очень быстро и
ситуация крайне динамична). Время - это деньги
как заказчика, так и исполнителя.
 На заметку - Agile технологии успешны именно
потому, что они:
 Уменьшают время разработки
 Сокращают количество требований

29. Анализ
Взгляд сверху
 Необходимо уметь смотреть на решение «вне
деталей». Иначе - за лесом теряются из виду
деревья.
 Важно уметь видеть ситуацию в целом, со всех
сторон и с разного расстояния.

30. Правила Аналитика
Комильфо аналитика

31. Правила Аналитика
 Найди свой велосипед («Все уже придумано до нас»)
 Расписание на послезавтра (анализ трендов)
 Пингвины – не летают! (правило Парето, бритва Оккама)
 От частного – к общему, от общего – к частному.
 Стоя на вершине Фудзи (Как видеть лес за деревьями)
 Кто не рискует… (время-деньги-риски)
 Стакан на половину полон или на половину пуст?
 С заказчиком – о заказчике и на одном языке (наука
переговоров и постановки вопросов).Эта
хорошая привычка говорить «нет»
 Болезни роста (или о бабушкиных комодах)

32. Вопросы?
Андрей Вербицкий
LinkedIn: Andrey Verbitsky
Skype: Andrey.Verbitsky
Email: Andrey.Verbitsky@gmail.com