вступление
Метафорическая концепция технического долга стала модным словом в деловой среде. Эта концепция - одна из наиболее частых причин ухода технических директоров из самых известных технологических компаний.
Чтобы правильно понять феномен технического долга, нам нужно использовать экономическое определение долга.
Что такое долг?
Итак, что лучше: купить что-то на свои деньги или использовать кредит, создавая долги? Конечно, безопаснее не иметь долгов и не платить банкам проценты.
Однако, если вы хотите сделать более значительные вложения, вам нужно будет сократить свой бюджет. В этот момент нужно принять правильное решение. Стоит ли вложение? Если положительный, то вы можете сформировать долг, решить свою проблему и выплатить долг в ближайшее время.
Точно так же это работает с техническим долгом. У вас есть цель создать определенный продукт. Вы быстро развертываете, включаете все необходимые функции, и результат готов.
Однако структура модуля в базе кода сбивает с толку. Вот где все начинается.
Вопрос в том, как бороться с этим хламом?
Очистка модульной структуры, устранение этого мусора займет несколько дней.
Так что, может, тебе не стоит тратить лишнее время. Если у команды появится новая задача по добавлению некоторых функций, вы сможете сделать продукт более привлекательным для пользователя.
Должны ли мы добавить эту функцию к существующему нечеткому коду и потратить пять дней или сначала очистить код, потратив пять дней только для того, чтобы иметь возможность правильно добавить новую функцию?
Практически каждый технический директор будет настаивать на том, что сначала необходимо прояснить структуру.
Но время - деньги. Часто компании необходимо как можно скорее завершить работу. Угадайте, какое решение примет топ-менеджмент? (Учитывая, что их первоначальная цель - рост прибыли).
Точно! В большинстве случаев они хотят, чтобы команда завершила работу над новой функцией за пять дней, а не за восемь.
С другой стороны, мы должны понимать, что вся компания выплачивает долг. Компания платит по долгам, выпуская продукт за пять дней, а не за восемь. Сразу после этого руководство разработало план развертывания новых функций в ближайшем будущем.
На этом этапе с модульной структурой кода будет еще больше проблем. Теперь добавление новых функций без устранения проблемы займет шесть дней.
Священный круг
Мы снова сталкиваемся со старыми проблемами. И компания должна снова принять решение. Потратить время на очистку кода? Или просто мгновенно добавить функцию?
Технический долг растет. Может быть, мы сможем заплатить за это, реализовав наш продукт в кратчайшие сроки? Может быть.
На самом деле краткосрочные выгоды от раннего развертывания будут незначительными по сравнению с потерей ресурсов на ремонт всей конструкции в конце дня.
Ситуация была бы совсем другой, если бы мы вложили эти несколько дополнительных дней в самом начале.
Технический директор против генерального директора: правда посередине
Я генеральный директор и, конечно же, моя мотивация - получение прибыли. Тем не менее, я определенно хочу работать надолго. Я понимаю, что компания - это не просто бизнес. Это команда профессионалов, и у них должна быть подходящая среда для выполнения своей работы.
Вот почему я хочу лучше изучить проблему и задать другим техническим директорам пару вопросов. Вот звезды техно-рока, которые любезно согласились мне помочь:
- Марк Энтони Моррис, генеральный директор / технический директор Hempchain.
- Маниш Джайн, соучредитель, технический директор Avata Intelligence.
- Джон Гвиннер, технический директор CareLabs Healthcare.
Вот что я получил в результате этих интервью
1. Как вы находите баланс между потребностями вашего бизнеса и возможностями команды разработчиков? Какая самая большая проблема?
Аутсорсинг. Сохранение навязчивой идеи клиента и качества продукции . - Марк Энтони Моррис, генеральный директор / технический директор Hempchain
Часто мы сталкиваемся с этой проблемой потому, что бизнес-потребности противоречат друг другу.
Чтобы клиент был доволен, он хочет сказать «да» пользовательским функциям (т.е.для дальнейшего развития). Затем бизнесу необходимо иметь несколько клиентов и меньше времени на развертывание (например, платформенные решения COTS).
Когда мы сталкиваемся с этими проблемами, мы обсуждаем фокус, краткосрочные и среднесрочные требования, а затем принимаем решение.
Самая большая проблема - это неопределенность: мы не знаем, сколько клиентов мы получим и насколько важно счастье одного клиента для денежного потока, и это создает стресс и конфликты. - Маниш Джайн, соучредитель, технический директор Avata Intelligence
Бизнес обычно думает, что развиваться легко. Один парень сказал: Вы наконец закончили? Я спросил их, сколько времени им потребуется на это. Я не могу этого сделать. Я спросил, почему они думают, что могут это оценить. Наконец они задумались. - Джон Гвиннер, технический директор CareLabs Healthcare
2. Стоит ли быстро выпускать новую функцию и не уделять достаточно внимания ее интеграции в общую архитектуру? В каких случаях это можно сделать?
На мой взгляд, стоит быстро выпустить новую функцию для демонстрации / целей MVP, только чтобы добавить клиентов в конвейер бизнеса. Можно также уделять меньше внимания интеграции, если общий дизайн разумно распределен с правильными микросервисами / бессерверными компонентами.
В противном случае, если бизнес рассчитывает на счастье одного или двух клиентов, вы делаете то, что им нужно. - Маниш Джайн, соучредитель, технический директор Avata Intelligence
Очень редко. Вы либо что-то сломаете, либо потребуете еще большей доработки, которая может подорвать работу. Однако, если модель данных не имеет никакого отношения к модели или она является автономной и делает пользователей счастливыми, сделайте это!
Все дело в пользователях. - Джон Гвиннер, технический директор CareLabs Healthcare
3. Верно ли, что иногда факт внедрения продукта важнее его качества? Почему?
Никогда. Дерьмо тебя погубит. Вы должны быть одержимы клиентами и предлагать только качество или ничего. - Марк Энтони Моррис, генеральный директор / технический директор Hempchain
Да, если общий дизайн разумно распределен, с правильными микросервисами / бессерверными компонентами. - Маниш Джайн, соучредитель, технический директор Avata Intelligence
Редко - но, возможно, для подтверждения концепции. - Джон Гвиннер, технический директор CareLabs Healthcare
4. Кто должен нести ответственность за некачественный продукт, если компания поставила задачу выполнить точное время, но разработчики предупредили, что крайний срок слишком ранний?
Такого никогда не должно быть, и это симптом обреченной и больной компании - устраните основную причину этого, будь то замена управления или используемых систем и процессов. - Марк Энтони Моррис, генеральный директор / технический директор Hempchain
Как технический директор, я хорошо заметен как в разработке, так и в управлении. Я думаю, что деньги останавливаются на мне, потому что я единственный, кто должен понимать обе стороны. - Маниш Джайн, соучредитель, технический директор Avata Intelligence
Управление. Однако часто виноваты разработчики. - Джон Гвиннер, технический директор CareLabs Healthcare
5. Можно ли изменить практику непрерывного добавления новых функций и вместо этого сосредоточиться на качественном и минималистичном списке функций?
Да, расширенные конвейеры CI / CD и продуктовые группы могут продвигать непрерывный поток функций и способствовать достижению результатов с помощью расширенных интегрированных агентов AI, которые контролируют передачу, прием, качество, эффективность и эффективность элементов, будь то макет страницы, цвет, контент, логика или любой другой функциональный или нефункциональный аспект клиентского опыта и целей компании. - Марк Энтони Моррис, генеральный директор / технический директор Hempchain
Получив эти ответы, я хочу сделать вывод
Прежде всего, мы видим, что проблема абсолютно естественна.
Чтобы выжить, компания хочет иметь больше клиентов. Никто не знает, сколько клиентов придет завтра. Вот почему стремление к большему количеству функций естественно.
В результате - у всей команды меньше времени, чтобы убедиться, что все работает как надо.
Более того, компания хочет быть доброй к каждому клиенту, потому что никогда не знаешь, что больше всего удовлетворяет пользователей. Вот почему вы стараетесь сделать все, что хочет клиент. Каждая дурацкая функция в кратчайшие сроки.
Считаю, что компания должна с самого начала наладить партнерские отношения. Когда ты стартап - тебе меньше терять. В этот момент постарайтесь объяснить каждому клиенту, что иногда вам виднее. Просто потому, что это твоя работа. Вы увидите, что это абсолютно нормально.
Быстро, но не слишком быстро
Быстрое развитие - это хорошо. Постарайтесь быстро внедрить новые функции, особенно это демо или бета-версия. Покупатели должны понимать, что это еще не идеально.
После этого у вас будет время сделать стабильную версию. Это хорошая идея, как найти баланс между потребностями рынка и техническими возможностями.
Кроме того, вы должны разработать правильное видение продукта. Потому что создание программного обеспечения всегда связано с удовлетворением потребностей пользователей и завоеванием рынка.
Нет однозначного ответа
Третий вопрос самый противоречивый. Для одного человека ответ очевиден, но в целом неочевиден. На мой взгляд, здесь нужно полагаться на собственный опыт.
Поскольку мой четвертый вопрос тоже был немного провокационным, я получил очень разные ответы. Тем не менее мой вывод прост.
Если вы видите, что что-то не так - разберитесь. Ваша работа должна быть сделана идеально. Если результат плохой - обе стороны должны решить проблему. Худшая ситуация, когда руководство обвиняет разработчиков, потому что оно имеет право винить.
Резюме
Как бизнес, вы должны быть ориентированы на клиента. Более того, вы должны получать прибыль. Постарайтесь реализовать все, что хочет ваш клиент. Постарайтесь сделать это быстро.
Однако убедитесь, что у вас достаточно времени, чтобы сделать свой продукт устойчивым, и не бойтесь объяснять пользователям, что вам нужно дополнительное время, когда оно вам действительно нужно.
Наконец, будьте естественны. Помните, что клиент очень важен. Но важна и ваша работа. Компания важна, но важен и каждый сотрудник.
Если вы будете помнить об этом, вам будет легче найти баланс между потребностями каждого.
Если у Вас возникнут вопросы, не стесняйтесь обращаться к нам.
Вперед и удачи!
Первоначально опубликовано на Inveritasoft.com 5 мая 2020 г.
