Когда чрезмерное проектирование — хорошая идея
12 мая 2022 г.Как часто вы работали над проектом, который ТРЕБУЕТСЯ сверхинженерным и должен быть «интернет-масштаба»?
Эти проекты предполагают массу допущений — обработка миллионов пользователей, сотни запросов в секунду и огромные потребности в хранении. На создание этих крупномасштабных функций уходят месяцы.
Задержки будут. Заинтересованные стороны разочаровываются. И тем не менее, ваша команда делает это.
К сожалению, единственным пользователем является Стив из отдела маркетинга. Ему нужно было отправлять по электронной почте модный отчет раз в неделю.
Я сталкивался с этой ситуацией ОЧЕНЬ МНОГО раз в своей карьере. Иногда я был причиной проблемы. В других случаях мне приходилось отговаривать людей от уступа.
С годами я понял, что правильное время для перепроектирования проекта зависит от одной вещи:
Понимание проблемы, которую вы пытаетесь решить.
Какую проблему вы НА САМОМ ДЕЛЕ решаете, когда переусердствуете?
Инженеры очарованы идеей «Что возможно?». Мы любим строить вещи и думать о будущем. К сожалению, это волнение приводит к проблемам сверху.
Думая о том, «что возможно?» добавляет размах.
Чтобы обойти это, вы должны сосредоточить свою энергию. Не принимайте требования как должное. Обратите внимание на предположения, которые делает ваша команда. Задайте важный вопрос заинтересованной стороне:
Какой результат хочет получить клиент?
Но ваше любопытство не должно заканчиваться на этом. Вам нужно понимать контекст , в котором вы работаете. Посмотрите, как работает ваша компания в целом.
- Каковы цели бизнеса в этом году?
- Ваша компания продает малым предприятиям или предприятиям?
- Какие ресурсы есть в распоряжении вашей команды?
Эта информация покажет вам, на какие компромиссы вам нужно пойти и куда потратить свое время.
Итак, когда именно вы должны перепроектировать проект?
Когда мне следует отправить программный проект как можно быстрее?
Я оптимизирую выпуск проекта как можно быстрее, когда цель состоит в том, чтобы учиться.
Стартапы — лучший тому пример. В первые дни начинающего бизнеса приоритет отдается соответствию продукта рынку. Цель состоит в том, чтобы найти клиентов и научиться быстро.
Можно написать достаточно кода, если это означает, что вы отправите продукт.
Мы всегда можем сделать систему более устойчивой позже.
Поэтому, если ваша компания исследует новый домен, оптимизируйте доставку по надежным системам.
Когда мне следует перепроектировать мой программный проект?
Я рекомендую перепроектировать проект, когда он отвечает двум требованиям:
- Система нужна для достижения долгосрочных бизнес-целей.
- У вас есть глубокое понимание проблемного пространства.
Чрезмерное проектирование идеально подходит для систем, которые являются ключевыми для бизнеса. Это старые системы, которые используются большинством клиентов и продолжают получать новые функции. Примеры включают поиск Google, ленту новостей Facebook или даже настройки разрешений пользователя в вашем веб-приложении.
Каждая из этих систем была переписана на протяжении многих лет. Хотя это рискованно, их успех обусловлен пониманием кодовой базы и согласованием переписывания с долгосрочными целями компании.
Я лично сталкивался с этим в своей повседневной работе. За последние шесть лет моя команда перенесла наше приложение на три разные технологии баз данных. Каждая миграция того стоила, пока мы не столкнулись с сочетанием масштаба трафика и вариантов использования, которые довели систему до предела.
Каждое переписывание было успешным благодаря тщательному планированию, согласованности целей и [разумной оценке проекта] (https://www.buildthestage.com/no-more-deadlines-tips-for-healthy-project-estimation/).
Использование Jobs to Be Done, чтобы узнать, когда нужно перепроектировать проект
[Структура Jobs to Be Done] (https://en.wikipedia.org/wiki/Outcome-Driven_Innovation) — отличный инструмент для оценки того, когда следует перепроектировать проект. Эта структура предлагает вам подумать о конкретной работе, для выполнения которой клиенты нанимают ваш продукт.
Мой любимый пример этого взят из «Состязания против удачи», когда автор пытается ответить на вопрос:
- «Почему люди пьют молочные коктейли из Макдональдса по утрам?»*
…то, что было общего у этих покупателей молочных коктейлей, не имело ничего общего с индивидуальной демографией. Скорее, все они выполняли общую работу, которую им нужно было выполнить утром.
«Помоги мне бодрствовать и заниматься, пока я делаю свои утренние поездки веселее».
Кристенсен, Клейтон М. и др. Соревнуясь с удачей: история инноваций и выбора клиентов. Нью-Йорк, штат Нью-Йорк, Harper Business, издательство Harpercollins Publishers, 2016.
Эти люди не просто покупали молочные коктейли в качестве десерта к еде. Они хотели чего-то высококалорийного, легко потребляемого за рулем и быстро покупаемого по пути на работу.
Понимание конкретных результатов, которых пытается достичь ваш клиент, поможет вам понять, когда следует усложнить проект.
Когда конечный результат состоит в том, чтобы учиться, отказывайтесь от качества и отправляйте быстро.
Но когда цель состоит в масштабировании, тогда перепроектируйте свое программное обеспечение.
Как понять, когда нужно перепроектировать проект? Дайте мне знать в LinkedIn или Twitter .
Дальнейшее чтение
Хотите узнать, как стать успешным лидером, в котором нуждается ваша команда? Подпишитесь на мою рассылку , чтобы узнать, как это сделать.
Оригинал