Аналитики - убийцы проектов, или
11 самых страшных ошибок системных аналитиков при работе с экспертом Часто от руководителей проектов по автоматизации (внедрению, ИТ-консалтингу) приходится слышать, что при планировании проекта необходимо перезакладываться в заявленных сроках, финансировании и качестве, чтобы вероятность успешного завершения проекта была отличной от нуля. Много проектов не доводятся до конца - кончаются деньги, выходят сроки, ликвидируется организация-заказчик (испольнитель
).
Можно выделить много разных факторов, влияющих на такие плачевные результаты. Плохой менеджмент, неквалифицированные программисты, высокие цены, безответственное правительство.
Но очень часто все проблемы начинаются еще с формулирования требований к системе, написания ТЗ, построения моделей, словом, всего того, что ложится на мужественные плечи системного аналитика. Уже давно притчей во языцех стала важность качества этих самых начальных кирпичей проекта, на которых строится все его здание. А так как аналитик по своему профилю отличается и от программиста, и от руководителя проекта, важно помнить, что его роль подразумевает специфическую деятельность.
И мы оставим за скобками методологию анализа и стандарты написания технических заданий (хотя они, безусловно, важны), и сосредоточимся на следующем процессе. Большая часть информации, на которой строится системный анализ, становится доступной в процессе интервью. Как один из методов работы с экспертом и извлечения знаний интервью в настоящее время является наиболее адекватным, позволяющим получить информацию не из инструкций и документов (которые, по идее, написаны людьми и для людей), а из опыта живого человека, собаку съевшего в той области, для которой делается анализ.
Процесс работы с экспертом имеет ряд нюансов, с которыми, похоже, в той или иной мере сталкивались большинство работодателей, размещающих в тексте вакансий "Системный аналитик" требования "опыт проведения интервью".
С этой точки зрения хотелось бы остановиться на основных ошибках, которые вносят в информацию, выдаваемую аналитиком, много рисков для проекта.
1. "Термины". Это ясно и понятно. Всем. Термины и определения - основа основ любого стандарта, руководящего документа, инструкции. Однако часто почему-то именно при общении с экспертом аналитики временно "забывают" об этом. Ну, казалось бы, и так ведь понятно, что значит слово "реестр"
. Особенно если аналитик такое слово (не дай Бог, конечно:)) слышал или (что еще круче) не совсем чужой в области исследований. А к чему приводит недостаточное внимание к терминам, Вам скажет любой ... юрист. Причем, не только тот, который на спорах по программному обеспечению специализируется.
2. "Мне понятно". Фраза, которая может отсечь 80% информации от эксперта по данному вопросу... По сути, ошибка является продолжением предыдущей. Ведь уже свое видение слова "реестр" у аналитика есть, и как только он слышит "А потом мы заполняем реестр", в голове шестеренки состыковываются - ура, образ совпал, и делается заключение "ну, тут мне все понятно, идем дальше". Кстати, в приводимом примере под "реестром" компания-заказчик подразумевала отдельную сложную (десятки отношений, сотни атрибутов) базу данных, которая тянула на полстоимости проекта, но это уже другая история.
3. "Время". Часто интервью не укладывается по времени в рамки, заявленные заранее. И это вопрос как тайм-менеджменту аналитика, так и готовности эксперта. И еще - "аналитик-профессия творческая", то есть позволяет занимать позицию, не регламентируемую по срокам. А непредсказуемость по срокам - всегда головная боль в любом проекте.
4. "Содержание затягивает". Когда эксперт увлечен, это передается аналитику. В той или иной мере. И бывает, что содержание того, о чем говорится в интервью становится важнее его целей и задач. И тут появляются и локальные проблемы со временем и больше внутренних компромиссов из разряда "Мне понятно" и "Термины".
5. "Детали". Очень часто проявляется в начале анализа. Эксперт стремится уходить в детали. Ведь он большой специалист в обсуждаемой теме. И в деталях часто появляется вся важность этого процесса _для эксперта_. А для проекта? А надо ли прямо сейчас раскрывать все "137 способов наматывания медной проволоки на катушки индуктивности"?
6. "Ты не спросишь, он сам не скажет". Типичная ситуация, например, когда эксперту не очень интересно, чтобы его деятельность подвергалась анализу. Но вот ему сказали сверху, мол, "надо, Федя", и он пришел и даже на вопросы отвечает (и даже правду). НО даже в этом случае слишком очень много вещей кажутся эксперту настолько очевидными, что о них не стоит и говорить. Так, трудно представить себе ситуацию, когда техник авиакомпании будет в интервью сознательно обращать внимание на то, что знает, с каким усилием необходимо закручивать гайки или почему нельзя носить обручального кольца. Он это просто делает. И даже не обратит на этот факт внимания.
7. "Кто тут эксперт". Ошибка идет рядом с "термины", "мне понятно", "содержание затягивает", "детали". Пытаясь показать (почему и для чего, отдельный вопрос) свою высокую информированность в обсуждаемой теме, аналитик часто бессознательно хочет встать на позицию эксперта. Это часто приводит к неправильным предпосылкам для анализа, некорректному пониманию и описанию задач и формулировки ТЗ.
8. "Кто тут главный". Еще одна ошибка формы процесса интервью. Вопросы ответственности в таком важном, почти интимном процессе как интервью, часто оказываются предметом дискуссий во время этого самого интервью. Кто кому когда за что сколько чего должен из этих двух людей, которые участвуют в беседе? В результате - непонятные рамки взаимодействия, снижение доверия и отсутствие хорошего контакта между участниками проекта для обеспечения бесперебойной работы системы.
9. "Результат-далеко". Конечный результат проекта - довольно далеко от временного периода работы аналитика. То есть цель работы и мотивация на ее достижение часто сильно проседают именно из-за длинной петли обратной связи и отсутствия четких криетриев хорошо сделанной работы (чтобы оценить работу системного аналитика, как правило, нужен очень хороший программист или другой системный аналитик). И тут приходится довольствоваться средними результатами, если аналитик хороший, или плохими, если аналитик средний.
10. "Нотация-диктатор". Аналитики часто любят инструментальные средства, которыми пользуются. Любят почти как спутника жизни, любимую игрушку или самое себя. Отстаивают их "лучшесть" перед коллегами из "другого лагеря". И держатся этой позиции. И что происходит? Они очень хороши в своей методологии (нотации, CASE-средстве и т.п.), и при этом подстраивают весь окружающий мир под эту методологию (нотацию и т.п.). Вроде бы неплохо: именно это и есть основа системного понимания процессов, то есть то, чем и занимается аналитик. И навязывает эксперту модель взаимодействия, при которой аналитику _удобнее_ заполнять элементы модели в своей нотации. НО нотация - это всего лишь _способ представления информации_, вторичная структура. А первичная структура - это то, как информацию выдает эксперт. И об этом забывается. И выбрасывается из рассмотрения опять же до 80%.
11. "Эксперт - тоже человек". Многие из рассмотренных выше ошибок близки к этой. И все же часто забывают, что в качестве эксперта в интервью участвует человек. Че-ло-век. Со своими проблемами, текущим состоянием, своим восприятием, своим спобсобом думания и изложения информации. И что нельзя воспринимать его как машинку-для-выдачи-информации. Он это почувствует. И что? А, может и ничего. Может, и будет продолжать быть-такой-машинкой. А может и не вспомнить чего-то, не досказать, не перезвонить через неделю после интервью, чтобы добавить важное замечание.
Запись на бесплатный онлайн-тренинг по эффективной работе с экспертом
здесь
Аналитики - убийцы проектов