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

Начнем с того, что зададим себе следующий вопрос:

Что такое бизнес и как он работает?

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

Возьмем, к примеру, Amazon.

Если игнорировать сторону Amazon Web Services, Amazon - это большая платформа для электронной коммерции, которая не только продает продукты, но и предлагает другим платформу для того же.

В этом случае (упрощенные) бизнес-правила следующие:

  1. Клиент может выбрать товар
  2. Клиент оплачивает товар, используя один из доступных вариантов.
  3. Клиент может добавить адрес, по которому будет доставлен товар.
  4. Заказ размещен на Amazon
  5. На склад поступает запрос на отгрузку товара.
  6. Курьер забирает товар со склада.
  7. Курьер доставляет товар заказчику.

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

Представьте, что интернет исчезнет завтра, что будет с Amazon? Я предполагаю, что они продолжат работать, перейдя на другой носитель. Например, они могут открыть телефонную линию или физический каталог и начать принимать чеки по почте. По странной иронии судьбы Amazon даже может начать открывать магазины, торгующие камнем и строительным раствором. Конечно, время выполнения заказа увеличится до дней, если не недель, а не текущих часов или суток.

Надеюсь, к этому моменту вы начинаете задавать себе вопрос: Но почему это важно?

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

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

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

Бизнес будет работать и добиваться успеха независимо от того, какую технологию вы выберете: .NET, JavaScript, React, Angular, Python, AWS, Google Cloud, Heroku и т. Д.

Потребности бизнеса

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

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

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

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

Где все идет не так

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

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

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

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

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

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

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

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

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

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

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

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

Отправка неправильного сообщения

Хорошо, если вы инженер-программист, читаете это и думаете: «Да, бизнес просто этого не понимает». Что ж, у меня для вас могут быть плохие новости. Они это понимают. И причина, по которой мы находимся в этом беспорядке, скорее всего, в вашем поведении.

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

  1. Есть способы доставить быстрее
  2. Проблема (ы), о которых вы говорите, на самом деле не является проблемой. И если копнуть дальше, есть еще одна проблема, которая очевидна. Вы ждете, чтобы вам разрешили поступить правильно.

Чтобы помочь вам понять, что я имею в виду, подумайте о следующем: когда вы берете машину в сервис или идете к врачу, спрашивают ли они: «Вы согласны, если они хорошо выполняют свою работу?»

Я искренне надеюсь, что ответ будет отрицательным. Так почему вы считаете, что вам нужно это разрешение?

Компании слишком заняты, чтобы о них заботиться

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

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

Помните, мы рассмотрели концепцию технологии как инструмента?

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

Это требование работы и ожидание, которое всегда присутствует, но никогда не прописывается в описании должности или обязанностях.

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

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

Итак, что мы / вы можем с этим поделать?

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

Рефакторинг

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

Большая часть рефакторинга может и должна быть завершена за от нескольких минут до нескольких часов.

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

Вышеизложенное было определено в книге Мартина Фаулера по рефакторингу [1].

Интересный момент, который следует отметить при рефакторинге, заключается в том, что часто, когда вы пытаетесь сообщить о связанных с ним рисках и преимуществах, руководству все еще может быть трудно увидеть преимущества или принять необходимость рефакторинга. Это означает, что бывает сложно найти подходящее время для крупных технических долговых обязательств (А. Мартини и др.) [2]. Но не бойтесь, поскольку следующие пункты должны помочь вам укрепить ваши аргументы.

Иметь план

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

Достаточно хорошо в вашем контексте

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

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

Измерьте это

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

20% времени

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

Может быть сложно попросить бизнес выделить 20% времени на то, чтобы сосредоточиться на техническом долге, поэтому предыдущий пункт об измерении воздействия очень важен. Если вы можете доказать, что дела идут лучше, вам будет легче сделать ставку на какой-либо план.

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

Исследование A. Martini и др. (2018) [2] показало, что компании, отслеживающие время, затрачиваемое на управление техническим долгом, тратят в среднем четверть своего времени на такую ​​деятельность со средним значением 15–20%.

Что делать, если не получается получить 20% времени

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

Для более широкого уровня технического долга, пока у вас есть план, вы можете разделить работу с затронутой командой. Согласитесь, что в понедельник команда A тратит 3 часа, во вторник - команда B и т. Д. Это принесет другие проблемы, например, насколько легко передать ее, но если вы ее взломаете, результатом будет не только сокращение технического долга, но и лучшее взаимодействие между командами.

Еще раз ссылаясь на исследование, проведенное A. Martini et al (2018) [2], исследование показало, что инициативы по техническому долгу часто начинаются с индивидуальных усилий. Вы можете быть этим человеком в своей организации.

Используйте оценки в ваших интересах

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

Не злоупотребляйте этим, но используйте это для увеличения влияния и, самое главное, доверия.

Купите, если можете, в противном случае рассмотрите вариант с открытым исходным кодом

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

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

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

Сжечь и построить снова / Гринфилд?

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

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

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

Подумайте о том, как вы собираетесь работать с гринфилдом. Что привело к отказу исходной системы? Если вы привнесете те же взгляды и проблемы, тогда никакие новые проекты не решат исходную проблему.

Если вы все же решите пойти с нуля, подумайте о потенциальных проблемах, которые возникнут в будущем. Какие важные функции у вас есть в дорожной карте, которые еще нужно добавить в старую систему? Может ли старая система перейти в режим обслуживания? Как вы собираетесь выпустить и протестировать миру новую блестящую версию? Как вы собираете отзывы и какие показатели важны для вас? Вам нужно перенести все функции и возможности, или вы можете отказаться от некоторых из них [3]? У вас есть данные, чтобы принимать правильные решения?

Переход с нуля всегда очень заманчиво, но на самом деле для бизнеса это очень важное решение, а также вложение времени и денег.

Не будь героем

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

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

Найдите единомышленников в команде или компании и способствуйте изменениям в более широком масштабе. Это принесет пользу бизнесу и вашему рассудку в долгосрочной перспективе.

Резюме

Компании слишком заняты, чтобы заботиться о вещах, которые они наняли вам, чтобы заботиться о них. У них есть свои проблемы и проблемы, с которыми им приходится сталкиваться каждый божий день.

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

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

И, наконец, оставляю вас такой пословицей: «Где воля, там и путь».

Если вас интересует эта тема, напишите мне в LinkedIn или Twitter.

использованная литература

Первоначально опубликовано на https://digitalroast.com.