7 слабостей начинающего системного аналитика: руководство по борьбе с суевериями для начинающих
Писать сложносочиненные предложения и доводить задачи до блеска. Быть скромными и сворачивать с улицы, по которой гуляет черная кошка. Есть много правил, которые могут сработать в других областях, но мешают в IT.
Я собрала 7 основных заблуждений, которые свойственны младшим аналитикам — неважно, выпускникам или специалистам, осваивающим новую профессию, — и дополнила их рекомендациями.
Спойлер: рекомендации подкреплены авторским списком полезных книг, материалов и ссылок
Заблуждение 1. Писать, как русские классики
Исследователи до сих пор разгадывают послания в романах Набокова, а писатели равняются на слог. Мы вызовем улыбку преподавателя по русскому языку, если добавим в текст деепричастный оборот или опишем As-Is системы, как Тургенев природу. Но важно помнить, что читатели ТЗ — это команда разработки продукта и заинтересованные лица. Поэтому требования должны быть описаны для них:
- кратко, без лишней информации
- однозначно, без двусмысленностей
Пример плохого требования: Система должна производить поиск по названию товара из каталога; если же пользователь владеет информацией о коде артикула и использует его при поиске, система должна это распознать и, не выдавая ошибки, произвести поиск по коду.
Пример хорошего требования: Система должна искать товар по названию или коду артикула.
Что почитать:
– Разработка требований к программному обеспечению, К. Вигерс и Дж.Битти
– Пиши, сокращай,Ильяхов М., Сарычева Л.
Заблуждение 2. Быть перфекционистом
Аналитик бережно шлифует прототип или скурпулезно описывает взаимодействие системы и пользователя. Но во время согласования ТЗ выясняется, что изменение положения pop-up окна на экране или автоматизация шага кратно увеличивает затраты на разработку. В результате часть требований отклоняют/переносят, ПО выходит “неидеальным”, а внутренний эстет пускает горькую слезу.
Разработка всегда происходит в контексте. Если выбрана методология Agile, то выпуск продукта происходит с учетом идеологии MVP (minimum viable product). Если это проектная разработка, то продукт выпускается в рамках ограничений бюджет-сроки-скоуп. Поэтому при реализации продуктовых фич и доработок ориентируются на их приоритет. Команда ранжирует задачи самостоятельно или адресует вопрос заказчику/представителю заказчика в команде (бизнес-аналитик, менеджер продукта, владелец продукта). Неидеальность выпускаемого ПО — данность, которая позволяет выводить на рынок продукты и закрывать проекты в срок.
Что почитать: Agile Manifesto for Software Development | Agile Alliance
Заблужнение 3. Изучать систему по документации
Составлять впечатление о продукте по документации — все равно что подкидывать блины по картинкам из интернета. Чтобы разобраться в системе, необходимо получить доступ к тестовой среде. В зависимости от продукта и доступного материала, можно воспроизвести шаги из документации, пройтись по тест-кейсам, полученным от команды QA, или побыть в роли пользователя. Если в результате манипуляций вы найдете несостыковки или разозлитесь, значит вы на верном пути. Эмпатия к конечному пользователю и уважение к заказчику — залог успешной работы аналитика.
Что делать: практиковаться
Заблуждение 4. Быть душкой
В задачи аналитика входит выявление требований, прояснение деталей, согласование документации, — то есть задачи, связанные с ожиданием ответа от заказчиков и коллег. Важно обозначать сроки и вовремя напоминать о задаче, перепроверять сообщением или звонком, что запрос получен и не вызывает недоумений. Если адресат нарушает дедлайн, необходимо поинтересоваться, что ему мешает и возможно ли помочь с ускорением процесса. Быть настойчивым — это часть работы аналитика.
Что почитать: Я слышу вас насквозь, Гоулстон М.
Заблуждение 5. ДЕМОнизировать
Эффект наблюдателя, тестировщик от бога, сервер заговоренный. В сфере ИТ не избежать суеверий. Начинающий аналитик более всего боится сглаза перед демо. Можно повесить на дверь подкову накануне презентации, но лучше — провести репетицию показа. На встрече необходимо делать пометки, если система некорректно отработала кейс или не известила пользователя об ошибке/состоянии, и записывать требования к функционалу, чтобы при необходимости добавить их в беклог.
Что почитать: Думай медленно… Решай быстро, Канеман. Д
Заблуждение 6. Предпочитать переписку разговору
Эпоха мессенджеров не отрицает, а дополняет классические встречи и телефонные переговоры. Конечно, есть вероятность, что переписку издадут –как письма Чехова к жене — но лучше прояснить накопившиеся вопросы с коллегами голосом. Главное — отслеживать, когда время экономит переписка, а когда — короткий разговор.
Что делать: практиковаться (и, конечно, прочитать переписку Антона Павловича с женой)
Заблуждение 7. Заводить любимчиков
Развитие навыков системного аналитика сопровождается освоением инструментов: новая нотация, тип диаграммы, метод сбора требований. Когда специалист увлекается одним средством, то может добиться высокого уровня экспертизы, но при этом рискует злоупотреблять им. В арсенале аналитика должны быть разные инструменты. И пусть невозможно овладеть ими всеми одинаково хорошо, стоит иметь их в виду, чтобы применять в ситуациях, когда полюбившиеся способы оказываются бесполезны.
Что почитать: BABOK Guide v.3
Заключение
В качестве заключения дам небольшое напутствие начинающим. Невозможно одновременно развиваться по всем направлениям. Поэтому прежде стоит выбрать то, которое более других востребовано на текущем проекте или продукте. Удобнее всего отталкиваться от текущих потребностей и использовать их как трамплин для развития. Тогда, возможно, однажды получится преодолеть слабости и превратиться в джедая, виртуозно работающего в неидеальной ИТ-среде.
Об авторе
Татьяна Демьянова, Product Owner / System Analyst в команде CT Software в группе компаний CT Customertimes corp — CT Customertimes, CT Consulting, Masterdata, CT Cloud.
Развивает продукт CT Presenter & Remote Detailing.
Более 12 лет опыта в IT. Участвовала в разработке крупных корпоративных ERP-систем и коммерческих продуктов для внешних клиентов.
Ментор в сообществе Women in Tech Russia.
Автор фотографий: Alex Fokin
Instagram: @alexskywhale
