Вступление
Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.
Поддерживает и развивает всю систему команда аналитиков. За это время у нас выработались правила, которые, по моему мнению, помогут всем аналитикам (бизнес, требований) и менеджерам, сотрудникам поддержки и даже немного разработчикам в крупном enterprise сегменте.
1. Аналитика ноги кормят
Это правило придумал мой коллега. Если вы находитесь в одном здание с пользователями и ключевыми заказчиками, то их надо посещать и разговаривать с ними. Так как не все умеют четко и ясно выражать свои мысли письменно, иногда один 15 минутный разговор может заменить трехдневную переписку.
Игнорирование этого правила приведет к долгим почтовым перепискам и бесконечной формализации задач.
2. Рисуйте
Рисование схем бизнес-процессов и набросков интерфейса позволит понять задачу вам и легко объяснить свое виденье пользователю. Красивые схемы бизнес процессов производят огромное впечатление на руководство заказчика. Лично я использовал нотацию EPC с вольными добавками (достаточно просто для понимания и достаточно наглядно).
Игнорирование этого правила сделает вашу работу скучной приведет к тому, что вы будете тратить намного больше времени на понимание задачи и ее объяснение.
3. Упрощайте (или не усложняйте)
Аналитики и бизнес-аналитики склонны к усложнению задач чаще, чем бы этого хотелось. Регулярно это отрицательно сказывается на результате. Я считаю, что решать задачи надо как можно проще.
Где-то через год работы я понял, что думать надо по следующему алгоритму:
а) придумаем простое решение;
б) пытаемся выяснить почему не подходит;
в) немного усложняем;
г) пытаемся выяснить почему не подходит;
д) немного усложняем;
и т.д. пока решение не станет оптимальным.
Игнорирование этого правила приведет к созданию велосипедов и неоправданно сложных решений, которыми никто не будет пользоваться.
4. Опрашивайте всех будущих пользователей и всех участников процесса
Виденье субъективно, поэтому пытайтесь выяснить мнение всех, кого касается будущее доработка, даже тех, кто будет затронут смежно. На практике всегда есть активный пользователь, который гнет свою линию, но она может оказаться неправильной, так как он не знает всех подводных камней и деятельности других отделов так же хорошо, как и своего.
Игнорирование этого правила приведет к тому, что решение не будет устраивать всех, а будет удовлетворять только одного пользователя с которым вы работайте.
5. Докапывайтесь до сути проблемы
Пользователи постоянно просят какие-то кнопки на формах, какие-то фильтры на списках и не любят объяснять зачем. Но выяснив ответ на вопрос «Зачем?» вы можете придумать совершенно другое решение, которое возможно будет работать лучше и эффективней.
Игнорирование этого правила приведет к тому, что решение будет незавершенное или не будет отвечать всем требованиям задачи.
6. Решайте глобальные задачи
Например, вас просят сделать документ, чтобы включить отдел в процесс работы в вашей ERP системе. На основании этого требования вы должны ставить глобальную задачу «Автоматизация отдела плано-экономического отдела» и выяснять смежные требования, но и докапываться до сути, согласно правилу 5. Это поможет сразу разработать решение, которое в будущем вызовет меньше доработок.
Игнорирование этого правила приведет к тому, что задачи не будут решаться.
7. Пользователь нацелен на успех (результат)
Очень распространено заблуждение, что пользователь или заказчик не понимают, что им надо и слабо заинтересованы в результате. Миф появился из того, что они регулярно смакуют мелочи и там самым затягивают разработку. На самом деле, все пользователи и заказчики хотят результат. Не забывайте об этом!
Игнорирование этого правила приведет к развитию конфликтов.
8. Принимайте универсальные решение (не автоматизируйте автоматизированное)
Огромное количество направлений деятельности автоматизировано. Существует достаточно универсальных решения для торговли, ведения задач, бухгалтерии и т.п. Но каждый следующий заказчик считает, что именно его компания работет никак все и процессы никак у всех. Иногда это действительно так, но в большей части случаев легкое изменение процессов под классические сэкономит клиенту много денег, а вам много нервов.
Игнорирование этого правила приведет к лишнему расходованию ресурсов.
9. Исполнитель должен понимать, что он делает
Аналитики регулярно ленятся объяснять разработчикам суть проблемы, а те ленятся слушать и вникать. Необходимо, чтобы разработчик понимал, что он делает и зачем, а не просто «добавь кнопку, которая...». Это позволит разработчику принять взвешенное решение, а иногда и дать мудрый совет аналитику.
Игнорирование этого правила приведет к плохим решениям с точки зрения разработки.
10. Избегайте неоднозначности
Разбивайте задачу до таких деталей, чтобы виденье результата было однозначно для вас, для ключевых пользователей и для разработчиков. Это не всегда возможно, но стремится к этому необходимо.
Игнорирование этого правила приведет к решения не отвечающим задачам.
Рекомендованная литература:
1. "Разработка требований к программному обеспечению", 2004. Карл Вигерс
2. "Принципы работы с требованиями к программному обеспечению. Унифицированный подход", Дин Леффингуэлл, Дон Уидриг
Автор: alexmikh
