Reverse Engineering требований. Часть 3. Особенности сбора информации от тех. специалистов
Обновлено: 4 янв. 2019 г.
Всем привет. На дворе октябрь и мы продолжаем разговаривать про восстановление требований. Сегодня мы поговорим о той информации, которую нам могут предоставить технические специалисты вообще и разработчики, в частности.
Информация, получаемая в ходе интервью технической части команды, может быть чрезвычайно полезна. Давайте посмотрим, что можно ожидать от “технических” групп стейкхолдеров.
Implementation Subject Matter Expert / Tester (QA)
Эта группа стейкхолдеров может стать хорошим источником информации о реализации, однако имеет свои особенности. Технические специалисты редко бывают погружены в бизнес-детали происходящего. Они очень много знают про то “как” это работает, но часто затрудняются ответить на вопрос “зачем”. Это приводит к тому, что им тяжело бывает оценить актуальность функций. Все в их окружении продолжает утверждать, что конкретная фича нужна: у них есть документация, которая поддерживает, есть зависимые функции, есть баг-репорты от пользователей как на саму фичу, так и на смежные участки. Опираясь только на информацию этой группы пользователей, легко воспроизвести в точности старое поведение, со всеми его проблемами, включая несоответствие реальной потребности бизнеса.
Пример. На маленьком проекте по замене систем присутствовал лид QA, совмещающий роли Product owner и специалиста поддержки старой системы. Он хорошо ориентировался в старом бэклоге и прекрасно знал систему, которая должна была быть снята с эксплуатации. Однако заново проектируемая система имела совсем другие границы ответственности и должна была подержать процессы, до этого находившиеся за ее пределами. Это влекло за собой достаточно кардинальную переделку UX, в том числе устоявшихся подходов. Что, в свою очередь, вызывало резко негативную реакцию лид QA. В течение года команда сохраняла специалиста, как носителя экспертизы по старой системе, Project manager фасилитировал обсуждения и смягчал сопротивление сотрудника. После замены систем, по взаимному согласию лида, его планово вывели из проекта без ущерба для него, команды и проекта. И продолжили развивать систему.
В целом, направление общения сильно зависит от состояния и намерений человека. Если это сотрудник, который горит своей работой, он может предоставлять исчерпывающие ответы на вопросы. Тонкость заключается в том, что его ответы могут иметь чрезмерно избыточный уровень сложности и детальности, не соответствующий изначальному запросу. Здесь хорошо помогают встречи ограниченные по времени.
Вторая ситуация - когда человек выгорел. Он будет избегать общения с вами, и ответы будут односложные. В этом случае идеально организовать разговор ”по душам”, явно показав, что вы понимаете его состояние, но вы такой же наемный сотрудник, который выполняет свою часть работы. И чем быстрее вы будете получать ответы, тем меньше времени он проведет с вами. Если человек не настроен враждебно, эта тактика способна решить проблему.
В случае замены продукта, команды разработки/поддержки обычно не мотивирована помогать изучать его для последующего снятия с эксплуатации. Во многом это объясняется тем, что старая команда зачастую ассоциирует себя с решением. Люди строят какие-то карьерные и личные планы, связанные с их текущими обязанностями. К сожалению, иногда специалисты настолько “прикипают” к обслуживаемому решению, что начинают саботировать работу.
Пример. У одного крупного заказчика (многопрофильный стационар) был сложный ИТ-ландшафт из многих систем, интегрированных между собой и обеспечивающих автоматизацию процессов. Причем автоматизация не только покрывала практически 100% бизнес-процессов клиента, но и проникала очень глубоко в них. Настолько, что неполадки в софте могли парализовать работу целых служб, что часто было недопустимо. К сожалению, в какой-то момент компания, которая занималась разработкой и поддержкой центральной системы и ее интеграции со всеми другими, обанкротилась и ушла с рынка. Руководство клиента наняла одного из ключевых членов бывшей команды (пусть будет А) к себе в штат, для дальнейшего сопровождения системы.
В таком положении больница просуществовала достаточно долго, причем сотрудник не только поддерживал работоспособность текущего решения, но и развивал его, углубляя и расширяя. Однако, по прошествии времени разные регуляторные органы выпустили постановления, где был ряд требований, которые не могли быть удовлетворены одним человеком, в частности это интеграция с региональной шиной данных и сертификация в части защиты медицинских данных. Это, а так же понимание рисков, связанных с обслуживанием огромной системы только одним уникальным специалистом, вынудило руководство больницы искать нового поставщика ПО, что и вылилось в контракт с нашей компанией. Мы должны были полностью обновить набор системы. Наш продукт должен был стать центральной системой, остальные системы заменены на системы наших партнеров.
На первых этапах А декларировал понимание ситуации и готовность к сотрудничеству. Он быстро отвечал на наши запросы, помогал разобраться в том, как что-то работает. Однако, чем дальше мы продвигались, тем менее охотно А шел на контакт. Объяснения становились все менее детальными, важные подробности “забывались”, а после нескольких итераций “вспоминались”. Росло время ожидания ответа и высылки материалов. Через некоторое время менеджменту стало так же известно, что А демотивировал других сотрудников в части работы с нами (“пустая трата времени, все равно у них ничего не получится”). Специально затягивал сроки согласований требований, проведения работ и запуска в эксплуатацию.
После 6 месяцев, наш менеджмент эскалировал ситуацию на топ-менеджмент заказчика. Перестать работать с человеком не было возможности - многое в текущем ИТ решении держалось исключительно на его присутствии. Поэтому мы решили по максимум ограничить поступающую от А информацию, и перепроверять ее по другим источникам везде, где это возможно. Только после этого внедрение сдвинулось с мертвой точки.
Еще одна поджидающая проблема: технические лиды могут ставить акценты на красоте реализации, забывая о приносимой бизнесу ценности. В процессе обсуждения они могут излишне драматизировать об имеющихся технических проблемах. Настаивать на поддержке всех исключений по процессу, и с трудом идти на компромиссы.
Пример. На одном из проектов лид на протяжении двух недель блокировал выпуск релиза, ссылаясь на недостаточно хорошую реализацию в сравнении с тем, что было до этого, а так же на потенциально имеющиеся баги (воспроизводить их не получалось, но лид утверждал что "сам видел"). Поскольку речь шла об очень редкой ситуации для некритичного участка системы, project manager выпустил релиз без его согласия. Баг нашли через несколько недель и исправили в штатном режиме.
Business Analysts / Project Manager
В целом достаточно беспроблемная группа специалистов, находящаяся на стыке технических и бизнес групп стейкхолдеров и помогающая связать между собой потребности и реализацию. Не стоит от них ждать детальных описаний работы, но зато эти люди часто могут рассказать историю проекта, дополнив понимание контекста происходящего. Так же у них обычно есть список текущих проблем, хорошее понимание политической ситуации. Однако стоит воздерживаться от чрезмерной опоры на их поддержку и вовлечение в корпоративные игры.
Пример. При начале работы с клиентом мы столкнулись с тем, что начальник отдела АСУ, уже пожилой человек, не заинтересован в работе. Предстоял большой и сложный проект, и ему не хотелось дополнительной нагрузки. Поговорив с его подчиненным, который высказывал энтузиазм, наш менеджмент помог организовать мягкую смену руководства АСУ. Бывший начальник сохранил работу, но с него была снята ответственность за проект и он продолжил решать многие другие вопросы (закупки оборудования и расходников, поддержка действующего ПО и т.п.). В начале смена прошла на пользу и проект продвигался очень быстро. Однако в какой-то момент интересы нового руководителя были затронуты, после чего он начал уклоняться от сотрудничества. Наш менеджмент оказался в сложной ситуации: эскалировать заново было проблематично, так как мы сами участвовали в орг. перестановке. Ситуация тянулась на протяжении почти года, прежде чем накопилось достаточно фактов, чтобы топ-менеджмент больницы сам признал проблему и был готов с ней что-то делать. Сроки за это время оказались многократно сорванными, а финансовое положение проекта - печальным.
Тренинги от "Art of Business Analysis":
Data Science и машинное обучение для бизнес-аналитиков (8-9 февраля, 2018)