Действующие лица:

● JUNIOR — решивший стать аналитиком начинающий боец;

● MIDDLE — системный аналитик, который «понюхал пороху», получил опыт на
нескольких проектах и начал осознавать всю глубину профессии;

● SENIOR — аналитик с богатым опытом разнообразных проектов, большим
количеством навыков и теоретической подготовкой;

● LEAD — эксперт и профессионал в области системного анализа, обладающий,
помимо прочего, хорошими управленческими навыками и лидерскими
качествами;

● ООО «Наша команда» — компания-исполнитель, отвечающей за проектирование и аналитику;

● АНО «Госорган» — организация клиента.

Этап Разработки наступает в тот момент, когда программеры садятся писать код по проектному решению. Для непосвященных это всегда самый ожидаемый и значимый момент, когда должна случиться магия, а не вот это вот все. Предыдущие этапы воспринимаются как подготовительные, и бытует заблуждение, что их могут выполнить люди без специальной квалификации.

Как следствие, аналитики мыслятся обслуживающим персоналом проекта, которые готовят рабочее место для программиста. А это значит что? Что на этапе разработки аналитик, вроде как, и не нужен вовсе. Это бред: аналитик и разработчик всегда работают в жесткой спайке. Именно поэтому реализация проектов в парадигме гибких методологий разработки растет по экспоненте.

Опять-таки, нужно понимать, что в этих статьях мы делаем жесткое, олдскульное разделение на обособленные этапы, только чтобы разжевать конкретный предмет исследования — «уровни компетенций аналитика» (ссылка на вводную). А чтобы это сделать и не умереть от потока информации и оговорок, наш объект исследования — «проект» — нужно разделить на отдельные ломтики: Исследование —> Проектирование —> Разработка —> Тестирование —> Внедрение (ссылки). Потом, в боевой практике, вы в своей голове все это склеите и пережените. А пока — как в школе: алгебра отдельно, геометрия — отдельно.

Итак, вернемся к нашим баранам. Разработка — это этап «делания». Причем, к дуэту «заказчик-аналитик» добавляется третье лицо со своим видением, опытом и интересом — программист. Разумеется, это прибавляет веселья… (программисты — вы лучшие, люблю вас!)

Всю сложную гамму взаимосвязей и разделения обязанностей внутри команды аналитики, лучше всего объяснить на примере строительства. Где LEAD — главный архитектор проекта: он этот дом придумал, концептуально описал и, при желании, может разъяснить устройство любой его части от водоснабжения до самого последнего винтика. Может, но не будет, потому что у него есть SENIOR — главный инженер, который всю эту архитектуру не просто понимает, но сразу переводит в конкретные решения: что как где, когда и из чего строить.

Так вот, архитектурный проект и его решение были созданы на предыдущем этапе. А значит здесь их роль заключается в том, чтобы контролировать строительство. LEAD-архитекор контролирует заказчика, чтобы тот вдруг не решил возвести бассейн вместо жилого дома. А SENIOR бригадиров, которые отвечают за свои участки. Старшего — MIDDLEа и младшего — JUNIORа. Бригадиры здесь выполняют самый большой объем работ: они полностью обеспечивают деятельность строительно-монтажной бригады материалами, чертежами и другими ресурсами. Контролируют сроки работ и качество результата, постоянно принимая массу мелких, но значимых решений, которое требуются в моменте.

Как правило, несколько раз за проект, возникает ситуация, когда строители вносят значительные коррективы в проект в связи с реалиями объекта: обнаружены подземные воды, неудачная роза ветров, неподходящий для проводки материал и т.д. Такие новые вводные, если они не требуют глобальных изменений в концепте, обрабатываются и берутся на личную ответственность бригадиров: MIDDLE и JUNIOR. Большие изменения уже требуют включения SENIORа. И глобальная задача всей этой армии — построить утвержденный дом.

Ну, в общих чертах разобрались. Теперь на примере. И здесь я хочу, в кои-то веки, рассказать про позитивный пример «контролируемого звездеца» — проект, где все было сделано по красоте.

ООО «Заказчик» заказал развитие существующей управленческой системы. Предыдущая версия системы была выполнена с огромным количеством разнообразного функционала, большая часть которого не использовалась. Архитектура их системы сильно смахивала на замок Хаула, который они быстро хотели переделать в «уютное альпийское шале».

ООО «Наша команда» ошалевшим взглядом посмотрела на эту архитектуру пьяного кондитера, и пришла к единственному решению: найти критерии, по которым можно разбить все многообразие изменений. И нашла. Результатом этапов Исследования и Проектирования, стало не только техническое задание и проектное решение, но и разбивка требований на 3 блока:

Эта разбивка дала ПОСЛЕДОВАТЕЛЬНОСТЬ работ. Таким образом, этап разработки был хорошо подготовлен. Реализация первых 2х блоков заняла половину отведенного времени. И на самую высоко-рисковую часть осталось достаточно ресурса.

Занимались построением первых двух блоков:

• взаимодействовали с программистами и были их проводниками в мир заказчика (согласовывали и уточняли каждый вопрос);
  
  
• собирали и готовили данные для наполнения системы;
  
  
• принимали работу интерфейса;
  
  
• делали промежуточные демонстрации;
  
  
• самостоятельно вносили решения по небольшим корректировкам.
  

В общем, веселились ребята. Их деятельность на этапе Разработки закрыла 70% общего объема запланированных работ.

Оставшиеся 30% потратил на то, чтобы:

• утрясти концептуальные вопросы для изменения существующей системы под сложные блоки;
  
  
• реализовать блок 3;
  
  
• в самых сложных местах подхватить у младших коллег блок 2 (но без энтузиазма).
  
  

В целом, он веселился примерно так же, но в меньшем объеме и большей сложности.

Таким образом, SENIOR, MIDDLE и JUNIOR закрыли все работы на этом этапе. Чем же был занят LEAD?

В идеальном мире, здесь LEAD мог уже пойти на другой проект и раз в неделю проверять статусы. Но в нашей истории, как и во многих других реальных случаях, он занимался тем, что проектировал новый функционал системы, который заказчик по дороге придумал и очень хотел реализовать. Ну, скажем, ему вдруг понадобился гараж возле шале. За доп.бюджет. Но обязательно в те же сроки. И чтобы успеть встроить эту конструкцию в возводимую систему, LEAD собственноручно этим занимался.

К вопросу о доп.бюджете, который всех, уверена, заинтриговал. У опытных заказчиков обычно есть заложенный бюджет на риски. И по мере снижения вероятности риска растет желание этот бюджет потратить на что-нибудь новое и нужное. Поэтому, если ваш проект идет так, как надо, то почти наверняка, LEAD на этапе Разработки будет судорожно проектировать «гаражи», «бани» и даже целые «гостевые домики» строго в рамках сроков.

Резюмируя этот радужный пример, хочу сказать, что на этом проекте каждый был на своем месте, и включен в процесс. Как итог: отличная система, довольный ООО «Заказчик» и очень довольный директор ООО «Наша команда».

Для тех, кто в теме — во время тестирования мы получили незначительные, косметические замечания заказчика к функционалу, причем их количество варьировалось в рамках 5% от общего объема требований. А хоть бы я и хвастаюсь, зато от чистого сердца)).

Несмотря на все многообразие функционала на этом этапе, главное здесь — умение разговаривать с каждым участником процесса на его языке: слышать и понимать, говорить и быть понятым. Это очень редкий навык, но он приобретается. Одно из типовых требований к резюме системного аналитика — «умение общаться с программистами». 80% нашей активности здесь занимает коммуникация: вербальная, письменная, визуальная. Не смог объяснить — нарисуй. Не смог нарисовать — станцуй. Все равно как, тебя должны понять! Не уверен, что тебя поняли? Повтори. Уверен, что поняли? Закрепи успех и тоже повтори!

И только 20% времени аналитик может уползти в нору, поплакать, поработать с данными и побыть нормальным интровертом. Но по-другому нельзя. На этом этапе работа делается не твоими руками. А ответственность за нее понесешь ты (это в следующей статье «Тестирование» — ссылка). И какое бы ни было у тебя прекрасное и полное описание того, что в итоге должно получится, нельзя ни на секунду выпадать из процесса. Это все равно, что привезти на строй-площадку кучу материалов и уехать на полгода, надеясь, по возвращении получить именно тот дом, который был запланирован. Это невозможно. А так хотелось!

Но если грамотно распределить обязанности внутри команды, приоритетов и сроков реализации, то именно этот этап может дать самый очевидный для всех результат. Который, помимо прочего, сильно облегчит дальнейшую работу над проектом.

10е место: Не проверять свои решения в реализации.
Вы не можете ошибаться.

9е место: Безоговорочно верить программисту.
Он ведь тоже не может ошибаться.

8е место: Откладывать проверку на реальных данных.
Мы прекрасно все покажем на «Test 1» «User 1».

7е место: Общаться только документами.
Вы пишете очень понятно, поэтому документ все расскажет за вас.

6е место: Общаться только устно.
Картинки и описания — для слабаков.

5е место: Игнорировать технические проблемы, требующие изменений в вашем гениальном решении.
Ты ж программист — давай делай чудо!

4е место: Переложить коммуникацию с заказчиком напрямую на программиста.
Это как слепому с глухим поговорить.

3е место: Начать разработку с самого непонятного места.
Ведь самое непонятно не может сожрать весь ваш ресурс.

2е место: Отдавать все промежуточные правки и пожелания программисту сразу после их поступления от заказчика.

Понятно ведь: ничто не может уже измениться в ходе дальнейшей разработки. А если серьезно, то подожди: подумай, посмотри на то, какие еще впереди изменения и нужны ли эти правки в принципе.

1е место: Снять руку с пульса. Программисты разрабатывают — ну и хорошо. Нет! Не хорошо: делают они, а ответственность несете вы.

* Обращаю внимание для тех, кто не читал вводную статью: навыки суммируются при повышении квалификации. Это значит, что LEAD имеет все навыки SENIOR, MIDDLE и JUNIOR. SENIOR — навыки MIDDLE и JUNIOR и т.д.