ReScript, BuckleScript та інші звірі на React fwdays | 27 березня. Давай з нами!
×Закрыть

Бизнес-модель и архитектура: как обеспечить уcпешность проектов

Привет. Меня зовут Степан Новиков. В EPAM я занимаю позицию Solution Architect, и мой общий опыт работы над коммерческими проектами в ІТ — более 15 лет. За это время я примерил на себя несколько ролей: выполнял функции бизнес-аналитика, руководил отделом бизнес-анализа в одном из банков, затем вернулся в разработку, постепенно приобретая опыт в IT-архитектуре.

За эти годы я успел поработать со многими проектами. Какие-то из них были более успешны, какие-то менее. Обычно в процессе разбора неудач выяснялось, что одной из основных причин была проблема коммуникации между разработчиками и клиентом. Часто мы либо не понимали, что нужно заказчику, либо же не могли внятно донести ему необходимость и полезность того или иного технического решения. Итогом такого недопонимания становились продукты, которые, будучи замечательными с технической стороны, не отвечали потребностям и бизнес-модели клиента.

Я надеюсь, что данная статья поможет читателям не наступить на те же грабли, и даст понимание того, почему для создания хорошей архитектуры необходимо максимально проникнуться принципами работы компании клиента и её бизнес-потребностями.

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

Почему проекты фейлятся

Использование Waterfall — один из самых распространённых мифов о причинах провала проекта. Когда мы берем большую итерацию, набираем огромное количество требований и долго не синхронизируемся с заказчиком и его бизнесом, сложно говорить о нормальном взаимодействии и адекватной обратной связи. С одной стороны, у нас не будет представления об актуальных требованиях и потребностях бизнеса клиента. С другой — заказчик просто не будет понимать, над чем же мы работаем. Поэтому определенная доля правды в мифе о вредности Waterfall есть.

Однако было бы неправильно винить во всех неудачах только модель процесса разработки. Мы можем использовать популярный и эффективный Agile, но без нормальной коммуникации с клиентом, без понимания специфики его бизнеса этот подход сам по себе не гарантирует успех.

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

Ранее цифровые решения в большинстве случаев служили дополнением к существующим бизнес-моделям компаний, занимая лишь несколько строчек в данной канве. Однако сегодня для большого числа компаний в мире ІТ-решения становятся если не основой бизнеса, то одним из жизненно необходимых компонентов. А для кого-то и вовсе единственным инструментом для получения прибыли. Роль ІТ-специалистов и ІТ-решений для полноценной работы компаний растет, а вместе с этим увеличивается и уровень ответственности.

В то же время в конце 90-х и начале нулевых разработчики не всегда задумывались о сборе информации от заказчика. Считалось, что клиент сам должен собирать и формировать требования, спуская готовую документацию командам разработчиков. Естественно, такое положение дел приводило к ряду недопониманий и разногласий, а готовый продукт, кажущийся разработчикам вершиной инженерной мысли, мог не соответствовать потребностям и бизнес-модели клиента.

Со временем Scrum и другие Agile-подходы своим появлением привнесли новшества в эти взаимоотношения, дали понимание того, что с клиентом можно и нужно разговаривать. Появилась роль Product Owner, изменился подход к самой документации.

Отсутствие знаний о том, как работает бизнес заказчика и какое влияние на работу бизнеса оказывают качества системы, может привести к ряду последствий. Начиная на первый взгляд с безобидных — таких, как быстродействие системы или вероятность отказа при пиковой нагрузке на неё, до глобальных и сулящих бизнесу колоссальные потери. Вспомните обход защиты в PlayStation Network в 2011 году.

Бизнес-модель компании как основа для разработки

Необязательно быть «серийным предпринимателем», чтобы понимать базовые принципы работы бизнеса и его бизнес-модель. Прежде всего, это комплекс факторов, совокупность которых помогает компании привлекать клиентов и за счёт предоставления им товаров и/или услуг зарабатывать деньги.

Сюда входят: потребители (клиенты), продукт, каналы сбыта, взаимоотношения с задействованными в бизнесе сторонами, финансовые потоки, структура доходов и расходов, ресурсы. Для иллюстрации бизнес-модели может применяться знакомый многим инструмент Business Model Canvas.

Business Model Canvas авторства Александра Остервальдера и Ива Пинье

Во избежание проблем, связанных с коммуникацией и недопониманием, во многих компаниях работают команды специалистов, среди которых не последнюю роль играют ІТ-архитекторы.

Роль IT-архитектора в понимании бизнес-модели заказчика

IT architecture is the art and science of designing and delivering valuable technology strategy.
International Association for All IT Architects

IT-архитектору, чтобы построить свое решение, важно понимать, как работает бизнес клиента, каков контекст, с которым будет работать система, и как данная система будет решать задачи бизнеса. Без этих знаний архитектор, вероятно, не сможет быть эффективен — все предпринимаемые действия могут оказаться попытками автоматизации хаоса.

Также одна из важных задач в работе архитектора — формирование «опасений» (Architectural Concerns) касательно будущей либо существующей архитектуры, участие в коммуникации с клиентом и выявления соответствия клиентских ожиданий с реальными бизнес-потребностями и бизнес-моделью компании.

Например, на моей практике бывало так, что у представителей заказчика были завышенные ожидания качества системы, никак не подкреплённые потребностями бизнеса. Любое улучшение одной или нескольких характеристик качества связано с необходимостью инвестировать силы и время в дополнительную разработку, более дорогую инфраструктуру и поддержку системы. Также улучшение одной характеристики качества системы может негативно повлиять на другие.

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

Избежать подобных вещей поможет детальное изучение бизнес-контекста.

Выяснение бизнес-контекста

Предназначение бизнеса состоит в привлечении (новых) и сохранение (существующих) клиентов. Без клиентов никакое инженерное волшебство, умное финансирования или опыт работы не помогут удержать компанию на плаву.
Теодор Левит

Выяснение бизнес-контекста — один из первых этапов, необходимых для разработки правильной архитектуры ІТ-решения.

На данном этапе главная цель для нас — подробный анализ бизнеса клиента. Сюда входит детальное изучение бизнес-модели, цепочек создания ценностей и добавленной стоимости для заказчика, клиентов компании, того, почему они покупают продукты и/или услуги, от каких поставщиков и партнёров зависит успех компании, а также архитектура существующих ІТ-решений и основные требования бизнеса к ним. Полученная информация станет определяющей для успешности дальнейшей работы архитектора и команды разработчиков.

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

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

Стоит также отметить один из подходов к разработке, помогающий дать решение, которое бы максимально отвечало бизнес-модели заказчика — Domain-driven Design (DDD).

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

Как же нам получить эти необходимые вводные данные о бизнесе заказчика? Помимо изучения предоставленной документации и проведения интервью с представителями клиента, эффективным инструментов являются воркшопы. В рамках таких активностей есть возможность послушать точки зрения различных представителей заказчика, найти консенсус или же сразу принять решение.

Воркшоп с участием ІТ-департамента и представителей других отделов. Dilbert comic strip, Scott Adams

Часто воркшопы оказываются даже более полезны, чем интервью. Во многом, конечно, их успех будет зависеть от опыта и навыков того, кто их проводит: если воркшоп прошел не эффективно, то, вероятно, его подготовили или провели не на должном уровне. Например, свой первый воркшоп я завалил. У меня не было достаточной уверенности, а люди из бизнеса на руководящих позициях хорошо это видят, поэтому отказались принимать участие в нем. Следующие несколько мероприятий я провёл как помощник более опытных на тот момент коллег-архитекторов — набрался опыта и уверенности. После этого воркшопы стали проходить успешней и стали для меня эффективным инструментом работы.

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

Приоритеты и взаимовлияние атрибутов качества системы

A quality attribute (QA) is a measurable or testable property of a system that is used to indicate
how well the system satisfies the needs of its stakeholders.
SEI Software Architecture in Practice

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

Улучшая один из атрибутов качества, как минимум мы вносим новые затраты, как максимум — негативно влияем на другие атрибуты качества. Например, увеличение скорости работы системы может потребовать кэширования данных. А для этого нужно написать код, поддерживающий инфраструктуру, которая отвечает за хранение кэшированных данных. Или же наоборот, то, что нам понадобилось усилить безопасность, добавив шифрование, может негативно сказаться на быстродействии.

Очевидно, что для банка во главе угла будет стоять безопасность, а для трейдинговой фирмы — скорость работы платформы. И если приоритеты расставить неверно, то в итоге мы получим решение, которое в лучшем случае не будет соответствовать потребностям клиента, в худшем — оставит его без прибыли.

Взаимосвязь атрибутов наглядно демонстрирует матрица взаимодействия от IASA:

Данная матрица не является завершённой, ее финальное наполнение будет зависеть от специфики решения

Поэтому, чтобы архитектура максимально соответствовала бизнес-модели компании, важно учитывать приоритеты. Каждое требования к качеству должно соответствовать реальной бизнес-задаче.

Приведу пример из жизни. Требование заказчика — время отклика системы не должно превышать 0,5 сек. Такая «хотелка» обошлась клиенту в кругленькую сумму, однако, как оказалось, конкретно для его бизнеса ценности она не несет — конечный пользователь системы просто не видел разницу, скорость не играла никакой роли для бизнеса. Деньги были потрачены зря. И обратная история: клиент хотел время отклика не более 0,6 сек. Проект был успешно реализован, отклик — 0,5 сек. Успех? Вовсе нет, компания потерпела неудачу на рынке, время отклика должно было составлять не 0,6 сек, а «быстрее, чем у конкурентов», у которых на момент выхода системы на рынок время отклика было уже меньше 0,4 сек.

Также следует помнить, что зачастую мы начинаем работу не с чистого листа, а с рядом технических ограничений, продиктованных решениями, которые кто-то уже принял и внедрил до нас. Например, у заказчика уже есть готовая система, элементы из которой он хочет повторно использовать в нашем проекте; уже куплен набор лицензий и так далее. Такие ограничения должны быть учтены во время расстановки приоритетов. Это не фокус нашей статьи, однако я решил упомянуть фактор ограничений, поскольку он будет влиять на будущую архитектуру.

Собрав все данные и расставив приоритеты качеств, мы можем переходить к выбору оптимальной архитектуры.

Поиск оптимальной архитектуры

Когда требования заказчика собраны и согласованы, приоритеты атрибутов расставлены, мы можем приступать к разработке архитектуры. Здесь нет никакой «серебряной пули»: каждый проект уникален, имеет свой ряд особых требований, поэтому нет и рецепта универсальной архитектуры, даже в рамках одной предметной области.

Подход к поиску оптимальной архитектуры согласно АТАМ

Наиболее распространенные подходы к дизайну и оценке архитектуры:

Attribute-driven Design (ADD). Согласно этому методу, решение о выборе архитектуры основывается на собранных атрибутах. Ранее ADD не всегда учитывал остаточные риски, связанные с применением тех или иных подходов, но последние версии ADD лишены данного недостатка. Цель ADD — получить максимальное качество при минимальных затратах.

Architecture Tradeoff Analysis Method (ATAM). Он сфокусирован на анализе архитектурных компромиссов и остаточных рисков. Если не вдаваться в подробности, цель ATAM — проверка правильности принятых решений. Мы принимаем решения для того, чтобы адресовать наши ключевые качества. Они начинаются с самых верхнеуровневых, например, выбора стиля: Layered, Monolith, Microservices и так далее. И двигаются в сторону паттернов и тактик. При помощи ATAM можно проверить, насколько каждое решение помогает в достижении нашей цели, а также какие риски оно несет и какое негативное влияние может оказать на другие качества.

Возьмем уже приведенный пример с безопасностью и скоростью работы. Добавляя шифрование, мы снижаем быстродействие. Архитектурным компромиссом (architecture tradeoff) в нашем случае может быть скорость. Если для нашего проекта она не имеет ключевого приоритета и добавление шифрования оставляет ее в заданных рамках, то такое уменьшение быстродействия приемлемо и не является риском.

Двигаясь путем анализа архитектурных компромиссов, мы выйдем на минимальные остаточные риски. Конечно, в реальности все может оказаться гораздо сложнее. Поэтому важно комплексно подойти к проверке выбора архитектуры, чтобы минимизировать риски её неправильного выбора и/или применения.

Проверяем выбор архитектуры. Лучшие практики

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

Quality Attribute Workshops (QAWs). Эта активность рекомендуется SEI (Software Engineering Institute) для сбора и приоритизации архитектурно значимых требований, которые можно использовать в качестве критериев проверки оптимальности решения и проведения приоритизации атрибутов качества. До этого этапа важно хорошо разобраться с бизнес-моделью, понимать основные драйверы бизнеса клиента. Упражнение помогает собрать требования заказчика через quality-атрибуты и идентифицировать ключевые из них.

ATAM. Я уже упоминал об этом подходе в блоке о выборе архитектуры. Если, используя ADD, мы принимаем решения, исходя из атрибутов, то метод ATAM дает возможность проверить соответствие принятых решений бизнес-целям и бизнес-драйверам заказчика, проанализировать возможные риски.

Приведу пример таблицы, основанной на ATAM, для самопроверки:

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

Описание определений:

Sensitivity — основной компонент или тактика, которыми мы достигаем архитектурно значимого требования.

Tradeoff — архитектурный компромисс, например, когда мы улучшаем более приоритетное качество системы за счёт менее приоритетного (вспоминаем пример с безопасностью и скоростью).

Risk — риски, связанные с решением компонентом или тактикой, например, что мы не достигнем целевых значений для качества, которое пытаемся адресовать, или повлияем на другие качества так, что по ним будет риск невыполнения критериев успешности.

Non-risk — хорошее принятое решение, которое позитивно влияет на достижения качества системы согласно бизнес-задачам.

Пояснение к значениям в таблице:

S1 — Microservices architecture positively affects changeability and scalability, it’s positive for Time to Market.

S2 — SQL database will guaranty transactions consistency to address financial transaction consistency required.

S3 — On-premises deployment will reduce operational costs of solution using existing data center.

T1 — Introduce initial costs for deployment. In the short term it will slightly increase costs by necessity of buying licenses and spin-up infrastructure, but in the long run it would decrease cost in comparison with constant billings for cloud services.

R1 — Risk of performance and throughput issues.

R2 — Central SQL database can be a single point of failure, performance issues due to locks and amount of data.

R3 — No uptime guarantee, availability at risk.

QA-1, QA-2 and QA-5 impacted negatively — residual risks.

QA-4 and QA-6 haven’t addressed yet.

Вывод, который можно сделать из данной таблицы: решение номер 2 (Central SQL Database) следует пересмотреть. Также необходимо принять больше решений, чтобы закрыть остаточные риски (R1 и R3), и адресовать те качества, которые здесь не адресованы.

Важно отметить, что этот пример верный только для контекста задачи, к которой он применялся и детали которой мы не рассматриваем. В случае другого контекста и/или бизнес-модели пример может быть не актуален. Если мы имеем дело с банком, где важно централизованно управлять финансовыми операциями, микросервисы могу оказаться не лучшим выбором архитектурного стиля.

Прототипирование (Proof of Concept). Это более предметная и «жизненная» практика. Предположим, у нас есть набор технологий, однако ранее мы не сталкивались с ним в реальной жизни, похожих кейсов также нет. В таком случае необходимо прибегнуть к разработке прототипа системы или ключевых её компонентов. Особое внимание стоит обратить на ее интеграцию с другими системами. Чем раньше вы протестируете свое решение на прототипе, тем проще внести изменения по его результатам.

Архитектурная оценка. Данный инструмент используют в основном большие заказчики, поскольку такая услуга может стоить дорого. Зачастую используется во время сравнения клиентом предложений от различных вендоров. Для оценки привлекается независимый подрядчик (одним из пионеров в этой области были уже упомянутые SEI), который также ориентируется на соответствие технического решения потребностям бизнеса компании, проводит воркшопы, привлекает к работе архитекторов из компаний-вендоров.

При этом «пробелы» в предложениях вендоров могут искать при помощи подхода ATAM, а результатом такого ассесмента, как правило, является набор рекомендаций касательно существующих и предлагаемых решений: технические недостатки и преимущества, финансовые аспекты той или иной опции, «дорожная карта» для рекомендуемой опции.

Выводы

В современных условиях мы все меньше можем говорить об ІТ как о какой-то отдельной структуре или сервисе. Вместе со стремительным развитием технологий цифровые решения становятся важной (а иногда неотъемлемой) частью современного бизнеса, продолжая или же дополняя его бизнес-модель. Поэтому успешность современных компаний часто зависит от того, насколько архитектура ІТ-систем учитывает это.

При этом максимально эффективное решение — это решение, когда IT-архитектура удовлетворяет не только требования заказчика, но и реальные потребности его бизнеса, учитывает бизнес-модель как в краткосрочной, так и в долгосрочной перспективе. Таким образом, ІТ-специалистам важно понимать принципы работы и устройства бизнеса, чтобы быть успешными. Точно также это работает и в обратную сторону — представителям компаний-заказчиков важно прокачивать свои технические навыки хотя бы на уровне общего понимания, поскольку именно взаимопонимание и слаженная работа обеих сторон поможет достичь максимальных результатов.

Список источников для ознакомления:

👍НравитсяПонравилось1
В избранноеВ избранном3
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: SoundCloud | Google Podcast | YouTube


11 комментариев

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

я слышал, многие компании рассматривают собственную бизнес-модель как конкурентное преимущество на рынке. вы полагаетесь на открытость, точность, объективность представителей заказчика и не изучаете бизнес непосредственно на месте?

даже если требования заказчика неизменны, отсутствие обратной связи и оценки работы исполнителя не позволяет исправить неточности и ошибки на раннем этапе, что приводит к повышенным затратам, затягиванию или срыву проекта.
не существует никакого «мифа» о вредности Waterfall.
эта ранняя модель разработки годится лишь для небольших проектов, если исполнитель хорошо знаком с предметной областью и не допускает ошибок.

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

Наверняка все из вас на разных этапах карьеры сталкивались с такой проблемой: пилишь задачу, вроде она простая и требования понятны, а потом выясняется, что требовалось реализовать по-другому. Время на реализацию потрачено, и уже подкрадывается дедлайн, а задача фактически не готова. Приходится на лету переписывать, вероятно с нарушением дедлайна. Теряются человеко-часы, а они стоят денег, а если эта проблема не у одного разработчика, а массовая для всей компании, то нарастает ком из просроченных задач, стоимость разработки растет, бизнес не может реализовать стратегии, и компания терпит убытки.
...
Возникает такая проблема из-за недостаточного погружения в задачу. Причин может быть много, вот некоторые из них:

отсутствие актуальной документации; (s: которую, и актуальную, мало кто будет читать. «код писать надо, не читать!»)
непонимание бизнес-процесса;
проработка требований не в полной мере;
человеческий фактор (источник знаний и исполнитель говорят об одном и том же, но понимают по-разному); (s: моя любимая тема порассуждать о гносеологии, за рюмкой чаю. программисты правда не умеют в большинстве поговорить на эту тему. «философия» и «психология» гуано, и т.п.)
личное разгильдяйство исполнителей и заказчиков; (s: у большинства программистов мнение что они труженники, а разгильдяи только менеджеры и заказчики)
и другие (каждый по своему наступал на грабли).

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

...(правильный) алгоритм работы станет следующим:

сбор сведений и формирование требовании;
команда груммит и продумывает решение;
назначается ответственный разработчик;
разработчик описывает техническое решение;
затем это техническое решение проходит ревью у команды и остальных погруженных в предметную область;
и только после того, как согласовали решение, разработчик пишет код; (!!!)
код-ревью;
тестирование.
(конец цитаты)
источник не важен, бардак и фейл будет всегда, если
вначале пишем код, а потом начинаем думать

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

слушаем внимательно
думаем старательно
делимся обдуманным
и если ок — пишем код, тестим, правим, тестим

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

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

скучно

Тут есть статьи от вована, где он рассказывает как его тра...обманывали все кому не лень и что ему на всех наплевать, вот там веселье.

Обожнюю, коли статті про важливість розуміння бізнес-процесів компаній пишуть люди з ментальністю працівника.

Процеси майже в усіх компаніях однакові (на високому рівні, звісно ж) та вимоги до всіх проектів однакові. Система мусить:

  • Скорочувати витрати: грошові, часові та інших ресурсів
  • Вирішувати як поточні, так й майбутні проблеми на всіх рівнях: виробництво, обслуговування, використовування, тощо.
  • Бути базисом для керуванням ресурсами на всіх етапах та ланках
  • Створювати додаткову цінність
  • Бути обґрунтовано гнучкою, щоб своєчасно реагувати на зміни ринку та модифікації процесів операційної діяльності

В цьому переліку немає Аджайлів, архітектур, фреймворків, прототипів та інших дуже-важливих-для-програмістів речей.

Почему проекты фейлятся

По множеству причин — банкротство, ссора партнеров, банальная смерть заказчика.

У вас описан только один, и довольно узенький кейс, типичной проблемы, которая называется «Я понятия не имею, как работает мой бизнес. Сделайте мне хорошо, я заплачу».

Тут поможет правильное формирование запросов с использованием EQ:
— Что вы почувствуете, если 10% не смогут зайти на сайт?
— Раздражение!
— А почему?
— Да они начнут мне обрывать телефон!
— А если перестанет работать автоматическая система приема оплаты?
— Досаду!
— А почему?
— Да опять надо будет работать с банковскими чеками!
— Ну а если сломается ваш бек-офис логистики?
— ААА! Ужас! Что вы такое говорите, у нас скоропортящийся товар — цветы, если не будет логистики то они могут завянуть из-за задержки!!!
— Но вы же писали, что у вас бизнес — воздушные шарики?
— Ну да. Воздушные шарики и цветы.
— Я чувствую, что вы еще многое не досказали, что может быть важным...
— Это правда. Я был в плохом настроении и ваш опросник меня просто выбесил.
— Может быть вы сможете его дополнить, когда будете чувствовать себя свежим и отдохнувшим?
— Конечно. Большое вам спасибо, что помогли мне избежать фейла проекта.

Но большинство наших специалистов работает очень примитивно — делай деталь по чертежу, шоб не було звездежу. Так что — шо маемо, то маемо.

По множеству причин — банкротство, ссора партнеров, банальная смерть заказчика.

Есть вещи, на которые мы можем повлиять и на которые повлиять нельзя. Речь идёт о том, что мы можем сделать для того, чтобы минимизировать риски.

Но большинство наших специалистов работает очень примитивно — делай деталь по чертежу, шоб не було звездежу. Так что — шо маемо, то маемо.

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

А своих людей в компании не выгоднее обучать?

Может быть выгодно, а может и нет — зависит от специфики.

В наших реалиях я встречал и такие кейсы в прошлом, когда компания предпочитала нанимать готовых экспертов, хотя, если даже посмотреть только финансовую сторону вопроса, то это может быть не выгодно, учитывая расходы на, поиск, наём и онбординг таких сотрудников. Я уже не говорю про переход людей из таких компаний в компании, предоставляющие возможности обучения.

Подписаться на комментарии