правила успешной работы бизнес-аналитика: от делегирования до перерывов

      Правила были разработаны в ходе работы, когда высокая текучесть кадров привела к необходимости быстро обучать молодых специалистов. Каждый из семи бизнес-аналитиков предложил по 20 правил. Многие из них оказались совпадающими, поэтому мы объединили их в единый документ. Окончательный список правил оказался гораздо больше. С разрешения коллег публикую его здесь.

    Общие принципы

      1. Проверяй документооборот 1 раз в день.

      2. Храни всю рабочую документацию на сетевом диске.

      3. Выбирайте только одну задачу на неделю, день или месяц. Расставляйте приоритеты и не занимайтесь всем сразу. Всегда возникает желание заняться другим понятным проектом. В итоге, важный проект будет отложен. Начиная другой проект, вы запускаете кучу процессов, вовлекая другие службы для решения уже других задач по новому проекту. Что нужно делать? Задавать следующий вопрос: Что еще мы можем сделать по проекту? Или запускать проекты, которые будут касаться уже других заказчиков и исполнителей. Ну или просто подождать.

      4. Нормируй свои задачи в зависимости от собственных способностей и особенностей. Планируй время на каждую задачу.

      5. Устанавливай себе приоритетность выполнения задач и придерживайся ее. Оценивай, как и на что задачи влияют, и не забывай обращаться к начальнику, если нужно.

      6. Решай проблемы сначала, затем проводи работу по выявлению первопричины. Используй метод «5 почему». Если проблема касается 1 участка или вида документа, расширяй ее и проверяй, нет ли аналогичных проблем, чтобы такая проблема больше не возникала в будущем. Не наказывай за проблемы, ищи решения и доводи до функциональных руководителей.

      7. Составляй, согласовывай и выпускай протоколы проведенных совещаний. Контролируй исполнение решений, принятых в ходе совещания.

      8. Не расширяй границы проекта, заканчивай то, что начато, и реализуй все новое после завершения текущей задачи. При расширении границ проекта есть риск неисполнения основного функционала и критичного нарушения сроков.

      9. Контролируй свое стремление к перфекционизму и помни, что лучшее – враг хорошего.

      10. Обращайся к грамотным и авторитетным пользователям (стейкхолдерам), если проект не идет.

      11. Старайся найти решение для обработки уже существующих в системе объектов, если запускаешь новый механизм.

      12. Реализуй инструменты для контроля проекта до его запуска в работу (отчеты, выгрузки и пр.).

      13. Информируй оперативно исполнителей о всех обновлениях в системе.

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

      15. Вводи проект в промышленную эксплуатацию только с соответствующими регламентами и инструкциями, которые нужно разрабатывать, согласовывать и проверять самостоятельно. При проверке инструкций привлекай коллег.

      16. Если обнаружил ошибку, возникшую по твоей вине, не паникуй и не пытайся скрыть факт. Разберись в причинах, оперативно устрани ошибку и предпринимай все меры для избежания ее повторения.

      17. Тестируй реализованный функционал на филиалах. По результатам тестирования филиалами, масштабируй. И не забывай ПИАРить.

      18. Делегируй и не пытайся самостоятельно справляться со всем. Активно ищи и привлекай заинтересованных лиц.

      19. Не дави на функциональные подразделения и не учи их, договаривайся с ними и уважай их.

      20. Планируй время отдыха и перерывы.

      21. Перед своим отпуском передавай дела коллеге, назначенному начальником. Убедись, что он принял дела и подтвердил это начальнику.

      Сбор информации по проекту:

      1. Общайтесь с заказчиками лично.

      2. Записывайте информацию в процессе ее сбора (в блокноте или на диктофоне), а затем согласовывайте ее с заказчиком, возможно, протокольно. Обеспечивайте безопасность на первом месте, особенно по задачам, касающимся важных данных и пользователей. Будьте готовы к тому, что встреч будет несколько и данные могут отличаться от первоначальных (детали, уточнения неизбежны).

      3. Определите «зачем?» возможно, после этого придет совершенно другое решение, которое будет работать лучше и эффективнее. Используйте метод «5 почему». Постарайтесь сразу заполнить паспорт проекта (цель, сроки, матрица ответственности, состояние до и после, границы проекта).

      4. Задавайте одни и те же вопросы разным людям, находите несоответствия. На повторных интервью снова задавайте те же перефразированные вопросы и снова ищите расхождения. Проверяйте сказанное основываясь на фактическом положении дел. Люди с первого раза редко рассказывают о настоящем положении дел, зачастую выдавая субъективную картину, в которой они занимают неоправданно центральное положение.

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

      6. Запросите документацию по процессу, как это должно быть.

      7. Анализируйте факты, статистику. Посетите производство, исполнителей, делайте фотографии рабочего дня. Не ориентируйтесь только на мнение начальства по бизнес-процессу. Помните, что цифры тоже могут обманывать. Данные могут быть ошибочными.

      8. Если задача не решается или информация не предоставляется, пишите на электронную почту, затем через день звоните, затем пишите служебную записку через документооборот на руководителя (служебные записки начальникам подразделений – за подписью начальника группы, служебные записки заместителям директора – за подписью главного бухгалтера). Задавайте вопросы по электронной почте. Если нет реакции, звоните. Если в документобороте задача не принята, значит, ее не делают. Мотивируйте исполнителя для выполнения задачи, объясняя зачем и какой будет результат.

      Подготовка схемы бизнес-процесса и технического задания (ТЗ)

      1. Визуализируйте. Рисуйте схемы бизнес-процессов, даже если это только наброски от руки — это позволит легко понять задачу и объяснить свое видение пользователю. Можно использовать сервис https://glvrd.ru/ для проверки текста.

      2. Техническое задание должно быть простым, понятным и однозначным, чтобы исключить любые недопонимания. Разбейте задачу на детали, чтобы видение результата было ясным всем — и вам, и заказчику, и разработчику.

      3. После визуализации бизнес-процесса и написания ТЗ, покажите его коллегам. Если им все понятно, отправьте на согласование заказчику.

      4. Если при чтении ТЗ есть хоть малейший шанс его понять не так, программист не упустит этот шанс. Поэтому ТЗ должно быть написано максимально простым и понятным языком.

      5. У заказчика должно сложиться ощущение, что это он написал ТЗ, а вы всего лишь помогли ему оформить и отредактировать.

      Работа с разработчиками/заказчиками

      1. Ставить задачи разработчикам (программистам) с конкретным сроком исполнения, контролировать выполнение, проверять результаты и направлять замечания. Необходимо добиваться исполнения задач и не задерживать их выполнение, чтобы избежать игнорирования в будущем.

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

      3. Стараться вовлечь разработчика (программиста) в весь процесс работы над проектом, поэтому важно сделать его соучастником процесса, чтобы он чувствовал ответственность за конечный результат.

      4. Делить проекты на более мелкие задачи, которые могут быть выполнены и показаны заказчику постепенно. Важно представлять результаты работы регулярно, даже если их объём невелик, поскольку заказчики зачастую интересуются только рабочим результатом.

      5. Ежедневно следить за прогрессом работ подрядчиков и задавать им три вопроса: что уже сделано, что планируется в ближайшее время, и что может помешать быстрому их выполнению задачи. При необходимости разбивать задачи для подрядчиков на более мелкие, контролировать результаты работы и поддерживать постоянный контакт с подрядчиками.

      6. Тестировать результаты разработок самостоятельно, чтобы выявить возможные ошибки и недочёты.

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

      8. Получать обратную связь не только от заказчика, но и от конечного пользователя продукта, учитывая все их пожелания, но при этом отдельно выделять критичные и не критичные для работы факторы.

ПРОДУКТИВНОЙ РАБОТЫ И УСПЕХОВ!!!

С уважением,
Руководитель проекта www.zamla.ru
Алмаз Кучумов