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