Результатом моей трёхгодовой работы в качестве PO/Functional Architector в медицинском домене является следующий значимый и уникальный опыт. В ходе работы над техническими решениями мировых компаний, их заказчиков и потребностей рынка я пришел к следующему важному заключению: основной ошибкой в разработке ПО является ошибка безграмотного проектирование систем. Это то о чем говорит Алан Купер в своей книге “Психбольница в руках пациентов”, а мой опыт является ярким подтверждением, что проблема существует и поныне.
Хочу с вами рассмотреть 2 примера из моей практики, “большую” и “маленькую” задачу, на примере тех систем, в которых мне посчастливилось поработать. И поделиться своим подходом к решению данные “ошибок”.
Пример из практики “большая задача”: интеграция новой готовой системы с ее функциональными возможностями в существующую платформу компании, а именно медицинскую платформа по исследованию клиник триалов и участию в цикле разработки новых медицинских препаратов.
“Маленькая задача”: общий бизнес-процесс компания заключается в разработке healthcare портала, который направлен на исцеление пациентов, в том числе улучшения показателей курса лечения: (приема препаратов), мониторинг процесса приема препаратов наблюдение симптомов на протяжении времени.
Если вы отправите жену в магазин, подумав о том, что хотели бы скушать домашнюю любимую пиццу, сказав при этом вашей супруге купить продуктов на ужин, но не сказав каких именно.
Какой будет результат? Будет еда, но 100% не будет пиццы, максимум частичное попадание (что-то из ингредиентов все таки будет приобретено чисто интуитивно). Будет потрачено время, ваше, как заказчика, жены, как исполнителя (разработчика), неоправданное ожидание и, конечно же, энная сумма денег на “еду” (в разработке - это проектирование функциональных возможностей системы).
Также произошло с моим 1 опытом по решению “большой” задачи, когда вместо mapping оценки конкретных требований бизнеса и функциональных возможностей системы, новая система 3-ей стороны стала просто встраиваться через “ну как-нибудь”, “ну что-то будет”.
Результат работы менеджмента по безграмотному проектированию системы:
была подорвана разработка основной, ключевой системы,
срывы контрактов с заказчиками,
уровень квалификации команды (команда стала просто распадаться) Итогом стало:
Команда проектирования системы осталась хорошей, все сделала правильно (себя, конечно же, только хвалим),
Встраиваемая система 3-ей стороны оказалась плохой,
Потрачен бюджет с 0.0000 и просроченный дедлайн в 1 год разработки,
Утрачена возможность в запланированные сроки прохождение медицинских исследований продукта.
Появились разговоры про поиски очередной и “плохой” системы. Вопрос: А как же всё-таки сделать надо было сделать?
В многочисленных и постоянно повторяющихся “ошибках проектирования систем” моих коллег я выработал для себя следующий подход решения возникающих ошибок.
Я кладу все факты на стол (это как игра в пазл), то есть рассматриваю все элементы системы, которые затрагивают конкретную задачу (что мы имеем на входе и какой результат хотим достичь на выходе) либо сам бизнес-процесс компании, зависит от случая и потребностей.
Затем я выявляю "периметр пазла", те создаю рамку всей общей задачи, по-другому - это рассматриваю границы "пазла" (границы самого проекта или конкретной задачи)
Затем смотрю что "нарисовано в самом пазле", те какие кусочки у нас есть и каких не хватает (какие шаги нужно сделать по направлению к завершению общей задачи/проекта)
Сажусь за проектирование “конкретных пазлов”, те предпринимаю те шаги, которые приведут команду к успеху и помогут реализовать задачу/выполнить проект.
Все идет так: сверху вниз, система существует для того, чтобы решать конкретную бизнес-задачу. Вы себе не представляете как много пациентов, так и врачей про это забывают и выбирают “удобный способ лечения”, вместо того, чтобы сфокусироваться над “эффективном способе победить болезнь”.
К чему это ведет:
“удобный” - сформирует ложное представление о процессе лечения и его результатах.
“эффективный” - работа с объективными метриками, правильное и целевое расходование средств, те “исцеление”.
В работе лично я придерживаюсь всегда следующего: каждая система должна быть обоснованной по функционалу. Те в системе должны быть только те функциональные возможности, которые необходимы для решения конкретной задачи, без лишней мишуры, так сказать.
