Почему Verizon обречен, и чему из этого можно научиться

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

Недавно я уже писал, что план Verizon (американский телекоммуникационный гигант) по передаче на аутсорсинг 2,5 тысяч рабочих мест ИТ-персонала индийскому подрядчику InfoSys «добром не кончится». Поскольку большинство компаний зависит от программного обеспечения, я должен объяснить, почему Verizon так сильно рискует, и как вы можете избежать подобной ошибки.

Совершенно очевидно, что основной причиной передачи ИТ-персонала Verizon является идея сокращения затрат. Предполагается, что сотрудники компании Verizon из США передадут все свои знания коллегам из InfoSys. И это теоретически позволит InfoSys выполнять работу, ранее выполняемую ИТ-персоналом Verizon, но по более низкой цене.

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

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

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

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

1. Код – это коммуникационная среда между людьми

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

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

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

2. Код отражает индивидуальность человека

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

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

3. Кодеры не являются взаимозаменяемыми ресурсами

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

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

Более того, эта неразбериха (которую я называю «техническим прерыванием») усугубляется, а не облегчается с увеличением числа программистов. Избыточное количество программистов неизбежно портит метафорический «бульон», особенно если они не вполне понимают, что они готовят.

4. Лучший вариант, когда программисты поддерживают собственный код

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

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

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

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

5. Код портится, если его не поддерживать

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

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

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

6. Техническое прерывание равносильно нестабильности системы

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

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

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

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

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

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

Пожалуйста, не подумайте, что я пренебрегаю инженерными способностями компаний, расположенных за пределами США. Отнюдь нет. Превосходных инженеров можно найти где угодно. Однако, хотя превосходные инженеры – это здорово, они не смогут компенсировать ущерб, наносимый руководством, которое беззаботно рассматривает инженерный персонал как ресурс plug-and-play.

Автор: Jeffrey James
Источник

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.

---

Еще рекомендуем

• Как Дженга

• Я все время делал это неправильно

• Больше против лучше

• Ради клиентов или для клиентов

• Обмануты (снова)