Зачем нужно столько разработчиков?

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

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


Для наглядного пояснения представим себе, что наш проект это корабль. Который мы уже некоторое время назад спустили с верфи, и он плывёт, радуя наш взор своим изящным профилем, а наш карман — золотыми дублонами. И вроде бы всё хорошо, но почему-то ему требуется куча людей только на то чтобы продолжать плыть. А хотелось бы, чтобы они вместо этого строили новые корабли….



Какие у нас возникают проблемы при условии, что проект не развивается (в скобках будет пояснение технического аспекта проблем). Написано не в порядке приоритетов, а как попало:


  1. Корабль пущен и плывёт, но у него есть небольшие течи. То камбуз затопит, то товар за борт вывалится, то рыба заплывёт. Казалось бы, это не критично, но лишает нас постоянно прибыли. (Баги, без них не обходится никакой проект. Нужны люди, которые будут их править).
  2. Законы акватории, в которой мы плаваем, часто меняются. И если их не читать и не приспосабливаться к ним, то рано или поздно с очередного причала раздастся залп, который разом разнесёт наш корабль в щепки. (Даже при условии, что ваш бизнес абсолютно легален, законодательство динамично меняется и добавляются новые требования, которые порой технически сложно реализовать. А без реализации можно огрести такие штрафы, что они мгновенно потопят проект).
  3. Периодически на корабль нападают пираты. У кого-то из них из вооружения есть только дрессированный дельфин с ятаганом, но если ваш проект реально большой, то рано или поздно приплывут тяжёлые галеры, вооружённые настоящими пушками. Отдельный нюанс состоит в том, что в мирное время вы спокойно пускаете их на борт, и они имеют возможность полностью знакомиться с вашим вооружением и оснасткой. А ещё они могут изучать вашу оснастку отдельно на суше, и при доле удачи имеют возможность дистанционно подорвать на вашей палубе вашу бочку с порохом. (Хакеры не дремлют, они могут изучить ваш проект, найти уязвимости в нём или его компонентах, и нанести вам огромные материальные потери. Для защиты от этих угроз требуется постоянная напряжённая работа разных специалистов).
  4. На суше часто случаются различные катаклизмы, и спрос на ваши товары меняется. Может случиться, что когда вы придёте в порт очередной раз, то бодрые грузчики накидают вам столько товара, что под его тяжестью корабль просто медленно уйдёт на дно. (Под действием различных факторов, вроде той же “чёрной пятницы”, вы можете получать сильные всплески нагрузки. Если вы к этому не готовы, то вы не только не получите профита, но и потеряете стандартный заработок и понесёте репутационные потери).
  5. Часть оснастки корабля работает согласно гороскопу, который составляет бортовой шаман. К сожалению, он часто закладывает за воротник, да и в лучшие свои дни не может видеть будущее дальше, чем на месяц вперёд. И порой бывает так, что на середине маршрута вы понимаете, что парус внезапно порвался, а порох отсырел. (Современные системы взаимодействуют с большим количеством внешних поставщиков и сервисов. И у них часто бывают свои проблемы. Нужно оперативно их отслеживать и иметь резервы на все критичные точки отказа).
  6. Будем реалистами. В море бывает разная погода, и иногда просто случается шторм. Конечно, у вас есть специально обученная летучая рыба, которая стоит в элитном аквариуме в каюте капитана, и ценится за то что умеет пучить глаза перед грозой — но, к сожалению, она тоже не всеведуща. (Сколько бы у вас ни было метрик, девопсов, дашбордов и прочего мониторинга — иногда что-нибудь просто падает. От этого ни застрахован ни гитлаб ни AWS ни любое чудесное облачное решение. И после этого нужно, чтобы были люди и возможность всё оперативно поднять обратно).
  7. Часто кажется, что раз корабль плывёт по одной воде, то значит может поплыть и по другой без каких-либо усилий и изменений. Часто капитан осознаёт ошибочность этого решения, только заметив, что вместо воды за бортом плещется кислота, а штурман матерится в весь голос, пытаясь вырулить между Сциллой и Харибдой. (Часто небольшие продуктовые изменения выливаются в сложные технические задачи, масштаб которых недооценивается. Например, вы всю дорогу считали цену товара в рублях. Решили добавить копейки. Что может пойти не так?)

Это всего несколько примеров того, для чего нужна целая команда, которая вроде бы ничем не занимается. Думаю, в комментариях можно добавить ещё много всего интересного. Но пока что мы рассматривали вырожденный случай, в котором не идёт никакого развития. Но вернётся в реальный мир — возможно, вы построили самый быстрый клиппер, и ваша “Катти Сарк” на момент схода с верфи была венцом кораблестроения. Но проходит буквально несколько лет, и рядом с ней проплывает атомоход, после чего команда дружно вешает себе на шеи по якорю и прыгает за борт, понимая, что здесь ловить уже нечего. Ну или спускает шлюпки и перебирается на атомоход….


Так вот — зачем вам такая большая команда, которая казалось бы пилит полторы фичи в месяц, а основное время, судя по всему, пьёт смузи и ругается по невнятным поводам?


  1. Вы стараетесь оснастить ваш корабль новейшим оборудованием, но постоянно возникают мелкие досадные проблемы — торпеды не запихиваются в жерла пушек, для турбин нет места, а эхолокатору почему-то требуется электричество. Команда бунтует и требует месяцы на изменения конструкции. Бунт подавляется, пушки рассверливают, эхолокатор запитывают от матросов, которые по очереди крутят педали на динамо машине. (С продуктовой стороны очень сложно оценить порядок работ, которые требуются на изменение в легаси проекте. Порой стоимость этих ребят может даже превосходить потенциальную выгоду. Или проще может быть построить новый корабль).
  2. Есть нюанс. Ваш корабль непрерывно в пути, и вы не можете зайти на верфь. Так что мало того что ваш надо поменять киль — вы делаете это прямо на ходу и порой корабль теряет управление и садится на рифы. Для того, чтобы это случалось реже, вы придумаете процессы, которые делают эти изменения менее болезненными — например, ставите одновременно старый и новый киль. Или меняете по кускам. Но всё это тоже стоит ресурсов. (Когда проект уже в продакшне, любое изменение вам может сломать всё что угодно. Есть много практик, которые помогают это избежать, но все они тоже стоят времени и ресурсов).
  3. Практика показывает, что иногда корабли размножаются. И при этом они живородящие. Иногда сложно заметить, как в трюме появляется и потихоньку вызревает ещё одно судно. В перспективе это прекрасно, так как позволит вам расширить флот и получать ещё больше дублонов. Но если вы не придумали, как вовремя сделать кораблю кесарево, то плод может перезреть и разорвать нутро материнского корабля к чёртовой матери, при этом так же погибнув. (Часто внутри одного проекта развиваются другие, и если не продумать вовремя архитектуру и пути разделения, то это чревато серьёзными проблемами. А если вы это продумали — то это всё равно трата времени и ресурсов).
  4. Когда на корабле несколько человек одновременно что-то делают, то то локтем в ухо заедут, то случайно в воду новую снасть скинут, то поспорят за длину гвоздей. Конечно, всё это решается — но разрешение конфликтов и разных видений тоже требует времени (размер команды имеет накладные расходы на взаимодействие).
  5. Решил ты поменять коврик на палубе. А под ковриком доски гнилые. А доски на ржавом настиле. А настила нового такого же размера нет. А тот который есть — не подходит по размеру к шпангоутам. Для того, чтобы поменять шпангоуты, нужен водолазный костюм, и 30 человек, которые будут воду откачивать. И в процессе этого из тьмы глубин всплывает кракен. (Часто один баг тянет за собой другой, и вроде бы небольшая задача обретает воистину космические масштабы).
  6. Чтобы заменить спасательный круг, нужно поменять носовую фигуру. Иначе руль отвалится. (Все компоненты взаимосвязаны, и рождают неведомую синергию, с последствиями которой тоже приходится бороться).
  7. Если с корабля вдруг исчез матрос, который знал все выражения лица рыбы-предсказательницы, то вы надолго можете остаться без предупреждений о штормах. Выхода два — или прикуйте этого матроса цепями, или учите всех членов команды разбираться в выражении рыбьего лица. (Bus factor. Потеря критичного разработчика может сильно усложнить и замедлить процесс разработки).

Перечислять можно ещё долго, но боюсь наскучить — надеюсь, что основную идею донести получилось, а дополнительные пункты можно добавить в комментариях. Удачного вам плавания!

Источник: https://habr.com/ru/post/480748/


Интересные статьи

Интересные статьи

Последние несколько лет мы при каждом удобном случае снова и снова обсуждаем, что же такое DevOps. Это уже порядком надоело, но раз всё еще происходит, значит есть проблема — проблема вза...
Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, ...
Инженер, бизнесмен и филантроп Билл Гейтс стал объектом атаки сторонников абсурдных теорий заговора, утверждающих, будто он причастен к созданию коронавируса. В своём блоге создатель ...
Ах, этот скромный светодиод состояния. Он есть практически у всей домашней электроники, у всех интегральных модулей, и вообще у всего, что потребляет электричество. В стародавние времена скро...
В этом выпуске: 00:38 — Разработчик создал дверь для кошки, которая пускает в дом только зверей с Bluetooth-пропуском, AnnieBronson 11:33 — ИИ научили играть в прятки, а он научился мухле...