Давно уже порывалась поделиться опытом написать.
Я периодически оглядываюсь в прошлое, анализирую свои поступки и их следствия, и делаю выводы типа «вот это привело к радости и счастью, а вот это - к печали и лучше не повторять».
Набивая очередную шишку, я решила, что пора писать талмуд под названием «Туда не ходи, а то снег в башка попадет», потому что «туда» ходят абсолютно все аналитики, а некоторые – раз по пять-шесть, «чтобы уж точно быть уверенными».
Большая часть описанного – это пережито мной на собственном опыте или наблюдалось мной со стороны на опыте коллег. Кроме того, я попросила руководителей проектов и наших аналитиков поделиться своим опытом и своими наблюдениями. И я расскажу вам, что из этого вышло.
Всем известно, что у каждой крайности есть своя полярность, которую не трудно представить, опираясь на описание противоположной. Думаю, это вы сможете представить сами.
Мы, СМСки, достаточно самокритичны, поэтому делимся своим опытом с желающими поучиться =)
Друзья, если у вас есть что добавить - пишите в комментарии.
1 Вера на слово
Она же – отсутствие критического мышления.
Это когда тебе кто-то что-то рассказывает, говорит, что что-то устроено вот так, или будет устроено вот так, а ты киваешь головой, кушаешь все это, и так и записываешь. А потом оказывается, что всё не так, или не всё, а кое-что, но это кое-что сильно влияет на остальное.
Так бывает когда, например, сначала концепция была одна, а потом она изменилась, а твой рассказчик не в курсе, или просто забыл об этом. Ну, или кто-то что-то понял по-своему и тебе пересказал так, как сам понял. Это подводные камни, пираньи, которые ждут аналитиков в тихом водоеме.
Короче, всё нужно ставить под сомнение и проверять.
2 Копипаст
Копипаст, или же «Взятие чьего-то (какого-то) документа за основу для создания своего» - совершенно чудесная вещь. Делается с целью экономии времени и ресурсов. Аккаунт тебе говорит: «У нас уже есть хорошее ТЗ, его надо только чуток подправить». Ну, или ты берешь какое-то абстрактное ТЗ листов на стопятьдесят (главное, что про него известно - оно написано по ГОСТ) и думаешь: «Я быстренько выкину ненужное и добавлю свое». Ага, как же. Быстренько. В процессе вычитки глаз замыливается, и - вот оно, удивление заказчика: «Мы – российская компания, а у вас в ТЗ какой-то Казахстан упоминается!». Ну, это в лучшем случае. В худшем – тебя выгонят из кабинета с позором (перед этим кинув тебе в лицо упомянутое ранее ТЗ).
Ну, или аналитик копирует какие-то части интерфейсов, или логики работы из других приложений (наших или чужих, не важно) без особого понимания, почему это подойдет, и без какой-то готовности отстаивать что это решение как лучшее.
Вообще, копипаст дело неблагодарное – тем, что включает веру на слово и блокирует ваше Шестое Чувство.
3 Игнорирование интуиции
Это, вообще, песня.
Например, пишешь ты спецификацию и тебя терзают смутные сомнения, что…:
- не для всех очевидно поведение функции, сценарий по которой ПМ решил не документировать во имя экономии времени (такое часто бывает, например, когда спецификация нужна вчера, но по плану работа над ней должна начаться через неделю);
- всё в документе кажется взаимосвязано и последовательно, но всё-таки где-то тут собака порылась и надо бы порыться и тебе, правда, сроки поджимают;
- как-то всё не совсем удобно и красиво;
- вот это решение не делать фильтрацию и сортировку, про которые заказчик сейчас забыл упомянуть, не «по фэн-шуй» и не «юзабилити»;
- надо бы заложить реализацию той пары отчетных форм, которые есть в регламенте заказчика, и о которых заказчик не упомянул в своем интервью;
- надо, надо поднять этот вопрос на уровне команды / задать его заказчику / включить описание в спецификацию / конкретизировать требование в документе;
- заказчика не устроит альтернатива, которую навязывают разработчики/архитекторы;
- вот эту большую и сложную задачку надо бы сделать сейчас, а не откладывать на финал проекта…
В общем, много сомнений, как смутных, так и вполне явных. Но ты надеешься на «авось, пролетит» и включаешь Лень, которая легко побеждает вкупе с Верой на слово.
Какие могут быть последствия?
Нууу, самое простое - это когда потом к тебе приходит тестировщик с этим самым нераскрытым вопросом, потому что он хочет написать баг, а разработчик требует ткнуть пальцем в задокументированное требование. И тебе всё-таки приходится дописывать кое-что в спецификацию. А разработчику приходится решать баг, потому что ему было совершенно не очевидно, как должна вести себя эта функция, и он написал код по тому, как смог сам примерно представить сценарий работы.
Похуже – если заказчик поднимает тот самый вопрос и таки- требует сделать по-человечески удобно / добавить фильтрацию и сортировку / добавить отчетные формы, про которые он, и правда, забыл, - и это будет стоить вам нервов, а команде, в зависимости от обстоятельств, может стоить лишней трудоемкости.
А самое ужасное – когда этот, нераскрытый, вопрос приводит к переделке некоего функционала. Ну, или к дополнительному функционалу, от которого можно было вовремя спастись ограничением требований.
4 Игнор официальных документов (договора, ТТ, ТП, ТЗ и т.д.)
А вот это уже самая великая самоподстава.
Например, ПМ и аккаунт в один голос говорят «Мы с заказчиками договорились, что это не делаем!».
В этот момент аналитик должен вспомнить фразу «Что написано пером, того не вырубить топором!». Потому что, действительно, не вырубить и делать всё равно придется. Со слезами. Заказчики – они же хозяева своего слова. Сегодня дали, завтра забрали. Даже если сейчас тебе (ПМ и аккаунт) не поверят, то потом (когда наступит это «придется»), можно будет злорадно произнести «Я же говорила!». Ну, и делать, конечно.
5 Очевидное
Обожаю эту ошибку.
Чаще всего аналитики совершают ее, когда ведутся на уговоры разработчиков минимизировать описание требований.
«Зачем описывать поиск в спецификации, очевидно же, как он работает!»
«Зачем описывать валидацию, очевидно же, на всех ресурсах валидация работает одинаково!»
«Зачем описывать табуляцию и горячие клавиши, это же очевидно! Возможность выделения текста на странице? Да это же очевидно!»
А потом начинается… Заказчик в шоке – он не может скопировать текст с нашей страницы. Заказчик зол – у него не работают горячие клавиши на нашей странице, поиск работает как-то странно, а элементы сохраняются без названия, потому что валидацию не сделали, и из-за этого система падает с критичной ошибкой.
Почему в «очевидных» случаях реализация не соответствует ожиданиям? Потому что у каждого человека своё очевидное и невероятное. Кто виноват? Разработчик? Нет, это же очевидно! Виноваты аналитики, которые не описали всё в спецификации.
6 Молчание
Иногда молчание - это не золото, а зло.
Этой ошибкой страдают излишне амбициозные или же не уверенные в себе люди.
Аналитик получает задачу, некое представление о том, что ему нужно сделать и уходит в глухую автономию. А ты гадай, чего он там пишет 8 часов не вставая со стула. Отсутствие обратной связи в виде вопросов часто означает бадабум через некоторое время. Когда я наблюдаю за аналитиками в «автономном плавании», я готовлюсь к самому худшему.
Аналитик может уйти в себя и думать над задачей долго-долго, гуглить, рыться в книжках и т.п., вместо того, чтобы посоветоваться с коллегами и быстро получить желаемое – чаще всего в ближайшем окружении находится человек, владеющий информацией или способный подсказать, у кого еще спросить, где что почитать.
В результате такой молчаливой и самостоятельной работы мы получаем недостаточно детализированные требования, не в том объеме, или описание не совсем того, не совсем так, как необходимо.
Или вот еще хороший пример: аналитик как-то расставляет приоритеты выполнения своих задач, не согласовывая их с приоритетами разработки. «Ваши планы передавали вам привет и
велели жить долго и счастливо».
велели жить долго и счастливо».
7 Спешка
Наверное, у каждого аналитика бывает острое желание быстро-быстро сделать работу. Прям вот рррраз! - и готово. Скоро-скоро выдать крутой результат, и получить звание героя аналитического труда (хотя бы на некоторое время).
На практике замечено, что впоследствии проект ждут разнообразные приключения. Например, не продумал аналитик взаимосвязи. И вооооот к нему потянулись с вопросами сначала разработчики, потом тестировщики, потом преемники-аналитики... Скучно не будет.
А уж если не продумать влияние функций друг на друга, и перед сдачей обнаружить их взаимоисключение (такое бывает на больших проектах)…
Попробуйте сами представить сколько работы прибавится всем-всем-всем.
8 Устные договоренности
Порой случаются неожиданности.
Переговоры были трудные, все в мыле, много спорили, доходило до криков… но вы получили то, что хотели. Другая сторона согласилась на ваши условия.
И вот вы радостно, с оптимизмом глядя в будущее, бросаетесь реализовывать требования. Проходит неделя, месяц.. Приходит срок демонстрации функционала.
А заказчик внезапно… не помнит о ваших договоренностях. Снова – здорово. Снова переговоры, вы аргументируете, что вы же договорились!.. Что заказчик согласился на ваши условия!.. И вы же в добрых партнерских отношениях… Как же так?..
«А была бы бумага…»
Сюда же относятся недокументированные соглашения внутри команды. Сегодня вы с разработчиками договорились делать функцию так, а завтра обнаружили, что сделана она несколько иначе (совсем иначе), а разработчики говорят, что вы так и договорились. Чем докажете свою правоту, господа аналитики?
Аналитик всегда должен помнить фразу «Что написано пером, того не вырубить топором!». Очень важно сразу после очной встречи или телефонного разговора зафиксировать принятые решения в письме и отправить другой стороне с просьбой подтвердить правильность записанного.
Так сказать, доверяй, но подтверждай.
9 Единственный источник информации
Отличается от Веры на слово степенью лени аналитика. В первом случае вы попадаете под гипноз харизмы собеседника (источника информации), во втором тупо ленитесь переспросить у других людей всё, что вам уже рассказал кто-то еще.
На практике часто бывает, что разные подразделения заказчика выполняют один и тот же процесс совершенно по-разному. Выяснив требования в одном месте и задокументировав их, аналитик подставляется на неизбежную переработку всего ранее сделанного после дополнения картины из других источников. И чаще всего это случается уже в момент согласования ТЗ.
О, ужас, не правда ли?..
10 Потеря причинно-следственных связей
Самая катастрофическая ошибка аналитика.
«Куда ты ведешь нас? Не видно ни зги!»
Отсутствие способности выстраивать ПСС наравне с буйной фантазией приводит к дырам в функционале и серьезным травматическим последствиям – как для психики разработчиков, так и для проекта в целом.
«Откуда взялось это требование?», «Зачем нам реализовывать эту функцию вот таким образом, а не таким?», «Как это повлияет на соседний функционал?», «А что будет, если пользователь нажмет на кнопку [Сохранить] не заполняя это поле?»..
Одним словом, аналитик должен точно представлять картинку в целом, а не одну функцию, и знать, откуда-куда-зачем-и-когда. А самое главное - ясно излагать это в документах и спецификациях.
11 Мелочи
Мелочи – это такая штука, которая достает медленно и с гарантией.
Аналитик протоптал дорожку к руководителю проекта (или старшему аналитику, или другому коллеге) с маленькими вопросами: «А как будет тут? А как сделать лучше, я не знаю? А что вот в этом случае? А где посмотреть?» То и дело, то есть, частенько, и не имея своего варианта ответа. Вроде мелочь, а отвлекает и раздражает. Создается впечатление, что своим мозгом аналитик не пользуется, а использует мозги коллег.
Ну, или начинает писать документ, не продумав сначала его структуру и последовательность изложения, не придерживается единого стиля… Потом тут надо поправить, там… И в итоге получается сумбур и отсутствие единой картины.
Иногда аналитик пытается в одном предложении уместить всё, что он знает по описываемой теме. В последствии читателю приходится переставить слова местами разбить это одно предложение на несколько, представить, что хотел сказать автор, а потом переписать всё заново. В несколько абзацев.
Иногда аналитик добавляет разделы в документ, или меняет свойства документа и забывает обновить его, забывает проверить корректность перекрестных ссылок (и на печати мы получаем не совсем то, что ожидали).
Бывает, что аналитик жалуется на неадекватность заказчика, мол, тот предлагает всякую ерунду, меняет мнение, сам не знает, что хочет. Т.е. аналитик перекладывает проблему на голову руководителя, вместо того, чтобы решить ее.
Часто случается отсутствие примеров в документах. Например, описана методика расчета, но нет примера с конкретными данными, и, как следствие, от взгляда аналитика ускользают какие-то нюансы, например, округление, размерность и т.п.
Бывает, что аналитик может описать сто частных случаев вместо описания одного-двух основных принципов, объединяющих эти сто случаев.
Еще бывает, что аналитик стремится приукрасить текст или рисунок, привнести частичку себя. Потом приходится идущему следом за ним всё это удалять. Ну, и неприятно, если заказчик тыкает пальцем в подобные «красоты».
«Мелочи не играют решающей роли. Они решают всё!» (с)
13 Не уверенная позиция
Она же - неготовность отстаивать свое мнение.
Разработчик спрашивает «А может вот так лучше?», а аналитик сразу соглашается: «Ладно, давай так».
Тут возникает вопрос: а зачем аналитик описывал свой вариант? Ведь было же там что-то ценное? Если не было, то напрашивается вывод, что аналитик – тюфяк, у которого нет собственного мнения, и сомнения в том, что он действительно проанализировал требования.
Всё это, конечно же, приводит к потере драгоценного времени.
13 Перегорание
Отдельно хочу сказать про неумение некоторых аналитиков вовремя остановиться. Они полностью вкладываются в работу, буквально уходят в неё с головой, «жгут», забывая пообедать, попить воды и даже сходить в туалет (да-да).
Такие вещи чреваты накоплением усталости, нервными срывами, снижением иммунитета и, как следствие, снижением качества и производительности работы.
Моя позиция в этом вопросе проста: всему свое время. Время работать и время отдыхать. И ответственность каждого человека - самостоятельно отслеживать свои физические и психологические ощущения и регулировать свою деятельность.
Аналитика – это искусство балансировать
В чем призвание аналитика, его главная задача?
Нет, не в том, чтобы четко понимать и переводить требования бизнеса на язык разработки.
Не в том, чтобы воссоздавать «общую картину» (всё это само собой подразумевается).
Нет, не в том, чтобы четко понимать и переводить требования бизнеса на язык разработки.
Не в том, чтобы воссоздавать «общую картину» (всё это само собой подразумевается).
Главная задача аналитика в том, чтобы, учитывая все ограничения проекта (бюджет, сроки) и «хотелки» бизнеса, придумать и продумать такую совокупность функций, которая будет наиболее полезной (в первую очередь) и наиболее удобной (во вторую очередь) для пользователя.
Ничего лишнего и всё, что необходимо.
П.С.: на семинар пришли некоторые из наших коллег-разработчиков, и, как водится, начались холивары: "Вы плохо пишете" - "Вы спецификации не читаете!"
Похоже, в ближайшее время мы создадим семинар "Ошибки разработчиков глазами аналитиков" =)
П.С.: на семинар пришли некоторые из наших коллег-разработчиков, и, как водится, начались холивары: "Вы плохо пишете" - "Вы спецификации не читаете!"
Похоже, в ближайшее время мы создадим семинар "Ошибки разработчиков глазами аналитиков" =)
