Меню

Eremeev Group / News

Строим сайты, пишем программы, занимаемся продвижением

Хранитель кода или дровосек?

 

В индустрии разработки программ и сайтов практически каждый день происходят стандартные, связанные между собой истории:

История 1:
Некто однажды заказал себе сайт или программу. Сайт или программа нормально работали полгода-год-два-три. Или даже десять! И вдруг понадобились какие-то доработки. Предыдущий разработчик «куда-то пропал», либо по каким-то причинам не может взяться за доработки. Найден новый, который готов сделать доработки и здесь начинается…

История 2:
Новый разработчик говорит: «Да тут полный [рифма от слова молодец], надо ВСЁ ПЕРЕДЕЛЫВАТЬ». И далее следуют тирады о криворукости предыдущих разработчиков, их неспособности сделать хоть что-то толковое и так далее.

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

Фишка 1: Паттерны программирования
Это даже не проблема, это закон IT-индустрии. Несмотря на внешнюю заформализованность нашей, программерской, работы, одну и ту же задачу можно спрограммировать по-разному. Скажу больше, по-разному это вообще даже не то слово. Все истории и попытки «внести науку» в виде паттернов программирования, готовых блоков и фреймворков добавляют удобства, но практически не решают проблему. Да, хорошо, что программируя под Windows можно не париться о том, как рисовать кнопку, достаточно «побросать» кнопки на проектируемую форму программы и… И начать программировать действия, происходящие при щелчках по этим кнопкам. И… (слишком много «И», но это для важности момента) И… здесь мы снова возвращаемся к проблеме множественной вариативности реализации одной и той же задачи.

Например, есть такое понятие, как «индусский код». Так вот, на ассемблере есть команда NOP (NO OPERATION) и HLT (HALT). Они обе подтормаживают программу, каждая со своими особенностями. Если вам надо так или иначе подтормозить процесс, вы используете в соответствующих случаях NOP или HLT. NOP просто ничего не делает, а HLT при особом подходе еще позволяет оттормозиться так, чтобы не греть саму микросхему процессора, что в определенных промышленных задачах может быть важно (энергосбережение). Иной раз приходится видеть, как одни разработчики используют NOP и/или HLT, а разработчики из Индии, зная сколько тактов процессора занимает то или иное вычисление, задают расчет совершенно ненужных цифр вместо того, чтобы остановить процессор и не жрать аккумулятор и не греть микросхему.

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

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

Либо вовсе получает от клиента отмашку на «переделать все, но, чтобы экраны/страницы выглядели как раньше».

Помимо профессионального уровня есть просто примеры разного подхода к реализации. Например, один программист делал сайты, не заточенные на высокую нагрузку. Работает для небольших фирм и никогда не сталкивался с тем, что на сайт может зайти больше миллиона посетителей в сутки. Это не хорошо и не плохо, просто программист, который делает определенную задачу для определенного клиента. У него нет цели построить промышленную архитектуру, чтобы сайт сельского нотариуса был технологически крут как главная страница Яндекса.

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

Допустим, взять код у каждого из описанных выше программистов и предложить поддерживать код друг друга – от обоих друг о друге можно наслушаться такого, что уши завянут сразу.
Фишка 2: Финансово-организационный вопрос
Вам сделали проект, вы за него заплатили N рублей. Кто сделал – не важно, это может быть и программист на удаленке и компания по договору, бывает всякое. Через полгода-год и т.д. «необщения» у вас и у того разработчика могут быть совершенно другие жизненные/бизнесовые и прочие обстоятельства.

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

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

Другими словами, причин, по которым «старый» разработчик не берется за доработку может быть множество и основная из них в том, что ваше сотрудничество изначально не подразумевало долгосрочных отношений. Вы отдали N рублей и получили продукт. Продукт, кажется, делает необходимое, вы подписали акт и счет-фактуру. Разработчик сделал нечто, что вы приняли и забрал деньги. И всё. Дальше вы живете с продуктом, а разработчику нужно добывать новые проекты и даже если вы приходите через год «нам тут надо поправить», то за год всё поменялось настолько, что для разработчика это уже совсем новый продукт. Если ваш разработчик — компания, то там наверняка сменился конкретный программист, делавший для вас работу. Если это «физик», то у него за год пролетело столько всего, что нужно будет «впираться» в проект заново.

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

Конечно, подобная организация процесса, наверное, гораздо лучше работает только на больших проектах и вообще не работает на «мелких», но, смеем заметить, по нашему опыту – работает везде!

Что такое «мелкий» проект? Например, сайт небольшой фирмы, который у разных исполнителей может стоить как 10 000, так и 100 000 рублей (в зависимости от наглости исполнителя и подходу к оценке своих трудозатрат). Мы делаем такой проект за 50 000 рублей, но при условии, что клиент заходит к нам на поддержку. Поддержка обычно включает в себя работы по наполнению сайта, ведению контекста, размещению сайта на нашем оборудовании (хостинг). В итоге первоначальные затраты на проект снижаются, а клиент получает «одно окно» для решения всех своих задач по сайту, который по сути и зачастую является лишь частью того digital-маркетинг-микса, который мы предлагаем. Стартовая цена сайта размывается в годовой поддержке, а клиенту с нами более удобно, чем с десятком разных поставщиков.

Примерно так же и с небольшими приложениями. Бюджет на разработку и контракт на год, по которому мы выделяем 5-10-15 часов в месяц программиста для всплывающих доработок. Если эти часы не используются – то они «сгорают», но в этом случае клиент всегда уверен в том, что любые просьбы по доработке будут выполнены, исходники не потеряются и вообще – ведь у продукта есть «хранитель кода», который не будет называть дровосеками предыдущих разработчиков, а спокойно доработает продукт при необходимости и проконсультирует пользователей.

Комментарии

Весьма кайфовое впечатление по первом прочтении. Стиль комфортен, заумности и казёнства нет. С моей точки зрения 5.
Только, пардон, просьба. Личная. В начале последнего абзаца вставьте пробел в тексте «Примерно так же …», а то общее суперское впечатление смазывается 🙂 Зануда, да? Зато проверка орфографии — бесплатно.

Добавить комментарий