У нас есть экстремальный опыт разработки программного обеспечения в Aista. Я иногда в шутку говорю, что «у нашего младшего разработчика 22 года профессионального опыта работы с программным обеспечением». Это ставит нас в положение, когда мы со временем накопили знания и опыт в том, что необходимо для реализации успешного программного проекта. Ниже вы можете увидеть 5 основных причин, по которым программные проекты терпят неудачу, согласно нашему опыту в этой области за всю жизнь создания программного обеспечения, которое просто работает!


1. Не знаю, что строить

Это гораздо более распространено, чем вы думаете. Пародия на это, конечно, заключается в том, что какой-то парень в Европе, увидев выписки по банковскому счету Марка Цукерберга с лишним 5000 евро, связался с какой-то аутсорсинговой компанией третьего мира со спецификацией, в которой говорится.

Сделай мне лучший Facebook

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

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

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


2. Позволить младшему начать проект

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

Исходная структура проекта становится архитектурой проекта. Если все решения были приняты кем-то без опыта, чтобы инициировать их, судьба проекта со временем обречена на провал. Хотя причины того, что джуниоры склонны начинать проекты, довольно просты. Старшие, как правило, заняты вашими «обычными проектами», обеспечивающими их выполнение. Возможно, это парадоксально, потому что ваши проекты BAU были инициированы младшим разработчиком, могу я добавить. Таким образом, самые опытные члены вашей команды редко получают возможность начать проект, что приводит к порочному кругу, когда вся программная основа вашей компании со временем неизбежно превращается в грязь. Большая шутка в том, что это в основном эквивалентно…

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

Когда изложено так, как указано выше, это, вероятно, имеет больше смысла. Это нужно остановить! Серьезно, это нужно остановить!


3. Раздутая технология

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

В Aista мы ПОСТОЯННО выбираем самую скучную технику!

Причины просты; У нас так много опыта, что нам нечего доказывать. И мы предпочитаем иметь счастливого клиента, чем изучать «новые и блестящие вещи», которые в любом случае неизбежно будут неактуальны через 5 лет. Худший случай этого, который я когда-либо видел, был проектом, который имел.

  1. Бессерверные функции Azure (потому что «это круто»)
  2. CosmosDB (потому что «это NoSQL»)
  3. Logic Apps (потому что «это круто»)
  4. 3 разных фреймворка для интерфейса (честно говоря, я понятия не имею, зачем они здесь)

При просмотре исходного кода проекта у меня возникло отчетливое ощущение, что главный архитектор, который инициировал проект, так просто потому, что у него были «дыры в резюме», и ему нужно было их заполнить. Излишне говорить, конечно, что проект был свернут после того, как было потрачено около 1 000 000 евро на попытки исправить кодовую базу, которая была буквально мертва еще до того, как она была на стадии БЕТА!

В Aista мы постоянно выбираем скучные вещи, потому что они работают, это доказано, и мы знаем, что клиент со временем придет и спросит нас о статистике, группировке и соединениях. Поэтому в 99% наших случаев мы просто отказываемся от NoSQL. . Не нужно начинать проект, используя что-то, что, как вы знаете, создаст проблемы в дальнейшем. Что касается логических приложений Azure и функций Azure? У меня есть одно слово для вас; БЛОКИРОВКА! Посмотрите, если сомневаетесь…


4. Отсутствие надзора

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

Вот почему мы в Aista начнем проект с сотен скучных вопросов о вашем проекте, чтобы мы могли избежать здесь как № 1, так и № 4. Лучше потратить один дополнительный месяц на то, чтобы понять требования проекта, а затем потратить еще 2 года на то, чтобы полностью отказаться от проекта и начать его заново, потому что разработчики реализовали нечто совершенно иное, чем то, что заказчик ожидал. Это одно из тех мест, где срабатывает «закон экспоненциально убывающей отдачи» как функции времени.

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

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


5. Заполните пропуски

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

Однако я дам вам подсказку; ЦЕЛОВАТЬ! Или его отсутствие, если быть точным…