Управление IT проектами. Создание функциональных сайтов

Как программисты могут обманывать. Уловки программистов-мошенников

2024-08-27 10:17:20 Время чтения 18 мин 123

Введение

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

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

Скрытие возможных проблем в будущем

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

Что может помочь?

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

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

Привязка заказчика к себе

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

В таких случаях возникает ситуация, когда программиста крайне сложно поменять, он неявно диктует условия развития системы (просто говорит: "Цыц, этого нельзя делать ни в коем случае!"). Это крайне неприятная ситуация для владельца продукта, т.к. он по сути оказывается в жесткой зависимости от конкретного человека.

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

для поддержки продукта не нужно владеть алхимией, нужно просто знать SQL и HTML;
у нас есть очень детальная документация по платформе с демостендом и примерами;
сайт клиента никак не завязан на центр и может работать полностью автономно (например, в защищенной локальной сети).

Что может помочь?

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

Должен быть доступен исходный код проекта.

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

В проекте должно быть минимальное количество такого кода, к которому все боятся подходить. Если есть такой код - у него точно будет некий незаменимый хранитель. А что будет, когда он уйдет или потребует зарплату на уровне программистов в США? Лучше сразу отказываться от таких фич еще на этапе разработки. "Бойся своих желаний" - очень мудрый совет в таких случаях.

Включение в ТЗ ненужного функционала

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

Дело в том, что любое требование в ТЗ требует дополнительное время и бюджет на реализацию. И каждая ненужная фича отнимает этот бюджет от будущей очень нужной фичи проекта (фича - это возможность, внедряемая в продукт).

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

Нужно всегда смотреть детали, а не полагаться на мнение специалиста.

Рассмотрим практический пример, у вас есть 1 млн на разработку продукта. Вы начинаете пихать в проект все подряд. Вам в этом с возбуждением помогает менеджер проекта, предлагая все подряд, чат-боты, разнообразные интеграции, перегонка данных в какие-нибудь системы аналитики и т.д. В итоге получилось под 900 тыс. "Отлично, все вложили, даже еще 100 тр осталось".

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

Рекомендуем изучить нашу статью о ТЗ для сайта.

Что делать, чтобы такого не было?

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

Отталкивайтесь от реальных потребностей, а не от того, что у сайта Х это же есть, значит и у нас должно быть.

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

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

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

Размытое описание задачи с последующей оплатой спорных моментов

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

ТЗ должно быть конкретным. Чем точнее написано ТЗ, тем меньше поводов для спора.

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

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

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

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

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

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

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

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

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

Как с этим бороться?

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

Предложение самых новых технологий

А в чем тут может быть подвох? Современные технологии - это же хорошо. Лучше сайт будет современным, чем доисторическим, разве нет?

Новые технологии, это не только клево, стильно и быть в ногу со временем, но и:

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

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

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

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

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

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

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

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

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

Мы - за быстрый подход серии правок. Нам проще в Bootstrap с типовой разметкой набросать форму, нежели делать это отдельно в Axure (средство макетирования). И делает это все по сути один человек, а не 5-6. Он должен знать только SQL + HTML в плане классов Bootstrap. И конечно подобный проект в несколько раз будет дешевле проекта с подходом, описанным в начале этого раздела.

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

Кто-то скажет, что бизнес-логика в хранимых процедурах - это ужасно. У всего есть своя цена (и конечно SQL процедуры где-то проигрывают в удобстве разработки объектно-ориентированным языкам типа C#, но мы идем за конечной выгодой для проекта, а не за абстрактной красотой и чистоту принципов).

Что еще можно урезать в проекте, чтобы сделать проект дешевле:

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

Растягивание сроков

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

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

Что могу сказать в нашу защиту (как представителя стороны разработчиков)?

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

Все это порождает тормоза в движении проектов. А программистам надо постоянно давать работу, им нельзя просто сказать: "Сегодня ничего нету, приходи завтра". И дело не в том, что мы такие чуткие, а в том, что человек просто пойдет искать работу в другом месте. Крайне важно для любой студии иметь некий буферный запас по загрузке.

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

Как заказчик может уменьшить растягивание сроков до минимума?

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

Заключение

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

Повторим их кратко: