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

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

Много говорилось о неудачных проектах. Интернет кишит мемами о том, как вся иерархия гоняется друг за другом, как пищевая цепочка в джунглях. Кто-то обвиняет программистов в написании кода с ошибками, а кто-то ругает руководство за невыполнимые обещания. Некоторые люди даже обвиняют клиентов в том, что они не понимают технических предпосылок и зависимостей этой отрасли. Но я почти не слышал, чтобы кто-то говорил о Техническом Долге или Кодовом Долге и цивилизованно решал этот вопрос, не тыкая друг в друга пальцами. Я ни разу не сталкивался с этим термином «Технический долг» от окружающих меня людей, на мероприятиях, которые я посещал, или в местных блогах, которые я читал.

Я столкнулся с этим термином только тогда, когда читал блоги и журналы из Силиконовой долины в США. Это означает, что большинство программистов и руководителей программного обеспечения, работающих в малых и средних компаниях по разработке программного обеспечения в Индии, даже не слышали об этом термине до сих пор. Итак, позвольте мне начать с объяснения самого термина. Технический долг или кодовый долг — это концепция в разработке программного обеспечения, которая отражает подразумеваемые затраты на дополнительную доработку, вызванную выбором простого (ограниченного) решения сейчас вместо использования лучшего подхода, который занял бы больше времени.

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

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

1. НЕТЕРПИТЕЛЬНЫЕ И СВЕРХУМНЫЕ КЛИЕНТЫ

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

Это приводит к тому, что клиенты совершают ошибку при выборе подходящей компании для партнерства, исходя из своих потребностей. Хотя отсутствие надлежащих навыков проверки не является их ошибкой, но некого винить в том, что они не обладают элементарной уличной смекалкой, позволяющей отличить мусорную компанию от настоящей. Теперь, как только они соглашаются работать с недостаточно талантливой командой, они задыхаются от своих нереалистичных ожиданий и сроков. Мало того, некоторые из них даже перебарщивают и показывают, насколько они умны, внося свои собственные предложения по дизайну и программированию. (#не все клиенты )

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

Если вы найдете хорошую команду разработчиков программного обеспечения, и они кажутся многообещающими, дайте им место, и они не почувствуют необходимости срезать углы, что приведет к уменьшению долга по коду в вашем проекте. И угадайте, что в большинстве случаев это вы, ребята, клиенты, которые оплачивают этот кодовый долг. Вы когда-нибудь слышали слова: «Запрос на изменение»? Держу пари, у большинства из вас есть! В идеальном сценарии вы никогда не должны слышать эти слова в своей жизни. Но такое случается редко. И чем чаще вы слышите эти слова, тем больше вы облажались, будучи клиентом компании-разработчика программного обеспечения.

2. Ленивые и хитрые менеджеры

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

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

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

3. ПРОГРАММИСТЫ

О да, я бы не стал заканчивать эту тему, обвиняя вас, ребята! Но эй, #не все программисты, верно? Ну да, но почти 94% программистов. По крайней мере, так думает С. П. Гурани, генеральный директор Tech Mahindra, когда пару лет назад он сделал шокирующее заявление о том, что 94% выпускников ИТ-специалистов не подходят для работы. Я точно не знаю, как он пришел к этому числу, но, будучи продуктом индийских инженерных колледжей и наблюдая за всей экосистемой ИТ-инженерии за последние 10 лет, я могу сказать, что склонен согласиться с утверждением г-на Гурани.

Я не пытаюсь спорить о том, 94%, 90% или 80%. Но если провести аналогию, почти все мы знаем, что нам нужна мука, вода и щепотка соли, чтобы сделать тесто, и скалка, чтобы сделать чапати. Но очень немногие из нас могут приготовить съедобные чапати. Это очень простой процесс, но все же требует определенного таланта и тонны практики, чтобы преуспеть в нем. То же самое и с программированием. Все мы знаем рецепт, но очень немногие на самом деле засучили рукава, запачкали руки и практиковали его столько времени, сколько требовалось, чтобы овладеть этим ремеслом.

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

Итак, в заключение я чувствую, что все 3 основные стороны в этом сотрудничестве должны разделить вину за компиляцию кода. Опять же, не принимайте эту статью как критику всего, что не так с индустрией. Это как и любая другая индустрия в мире, со своей долей ужасов и героев. Даже после 10 лет занятий этим я все равно не стал бы заниматься ничем другим в своей жизни. Мне нравится эта работа, мне нравится быть маленькой компанией, работающей над интересными проектами клиентов со всего мира.

Цель состояла в том, чтобы сделать все 3 заинтересованные стороны более ответственными и познакомить их с этой лежащей в основе мягкой потерей, которая постигла их из-за неправильного сотрудничества. Если команда разработчиков программного обеспечения хочет точно рассчитать и измерить свой технический долг, они могут следовать строгой модели процесса, основанной на методологии Agile или даже на методологии Waterfall. Когда вы будете следовать этому дисциплинированному подходу, вы сможете отмечать эти спринты по ревизии и ремонту отдельно, а в конце фазы вы сможете точно рассчитать, сколько из них вам нужно, и легко перейти к причина этого.

Я закончу это заключительной цитатой Сэмюэля Беккета: