Ответственность в разработке. Какие результаты должен вам гарантировать разработчик?

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

В чём разница между этой статьёй и остальными, спросите вы — и я отвечу так: во всех перечисленных ниже случаях получившиеся системы не оправдали ожиданий заказчиков.

Заказчик обратился ко мне для разработки системы таблиц. Предназначение — автоматизация процессов постановки и контроля задач сотрудников, организация базы знаний сотрудников и учёт договорных отношений.

У этого заказа была редкая особенность: у заказчика было чёткое понимание, какие таблицы ему нужны: как будут выглядеть поля, как они должны работать и т.д. В общем, на редкость подробное ТЗ и чёткое понимание желаемого результата.

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

Вот только спустя несколько недель активной работы заказчик ошарашивает меня следующим упрёком: "Мы с вами сделали уже кучу таблиц, и в это вложено много денег, а результата до сих пор нет!"

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

Я объясняю этот момент заказчику и спрашиваю, что конкретно не работает, потому что любые ошибки можно исправить, а таблицы доработать. В ответ не слышу никакой конкретики — снова размытое "результата до сих пор нет".

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

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

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

В данном кейсе я был должен:

И НЕ должен:

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

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

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

Чрезвычайно важно было сделать такую систему срочно — заказчик даже предложил двойную оплату при условии, что система будет создана не за месяц, а за 10 дней. Благо, сон для слабаков, и мне удалось создать эту систему в короткий срок, чтобы ей быстро начали пользоваться в “полевых условиях”.

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

Всё идёт по плану, система используется ежедневно. Заказы создаются, зарплаты рассчитываются, склады ведутся, расходы учитываются. Однако через какое-то время я захожу в эту систему для проверки работоспособности. И вижу, что ею не пользуются уже вторую неделю. Хотя никаких проблем или ошибок за это время озвучено не было.

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

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

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

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

В этот момент самое время напомнить, что из-за большой загруженности бригадир не заходил в систему почти 2 недели. Интересно, откуда же тогда появился такой завал и задержка в расчётах ЗП?

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

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

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

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

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

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

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

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

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

При этом в обязанности не входило:

Этот случай — показатель того, как чёткое и понятное ТЗ могло бы значительно облегчить процесс работы как для разработчика, так и для самого заказчика. Впрочем, также важно трезво осознавать свои ожидания от работы специалиста и быть готовым к тому, что не вс получается по щелчку пальца.

Заказчица обратилась ко мне за созданием таблицы фиксации "фотографии рабочего дня" каждого бухгалтера её агентства аутсорсинговых услуг. Ключевых целей таблицы было две:

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

Таблица была создана и запущена в работу достаточно быстро. Заказчица осталась крайне довольна, поскольку всё работало именно так, как она описала в ТЗ.

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

Кстати, забавно, что в дальнейшем мы поменялись ролями, и, после открытия ИП я сам стал клиентом в её агентстве.

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

Несмотря на то, что для заказчицы я:

Возникло следующее:

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

Заказчик обратился ко мне за разработкой таблиц для автоматизации процессов на швейном производстве.

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

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

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

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

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

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

При разработке всех систем я сделал следующие вещи:

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

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

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

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

Другие мои статьи и бесплатные шаблоны таблиц, а также ссылки на сообщества с полезным контентом по таблицам и мои контакты можно найти здесь:

taplink.cc/drobnitsavladimir

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

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