Работу мы начали очень активно, и заказчик был очень вовлечён в процесс. Завершив работу над первой таблицей, мы сразу же приступили к созданию второй, третьей и множества последующих, даже не останавливаясь на полноценном тестировании созданных таблиц в реальных рабочих условиях, поскольку у заказчика был отдельный сотрудник, отвечающий за интеграцию новых систем и организацию работы.
Вот только спустя несколько недель активной работы заказчик ошарашивает меня следующим упрёком: "Мы с вами сделали уже кучу таблиц, и в это вложено много денег, а результата до сих пор нет!"
Меня это заявление, конечно же, ставит в ступор, так как с моей стороны все задачи выполнены, все правки внесены, и все таблицы работают. Но, со стороны заказчика, этими таблицами банально никто не пользуется. Половину из них даже не тестировали в работе, каждый раз по разным причинам.
Я объясняю этот момент заказчику и спрашиваю, что конкретно не работает, потому что любые ошибки можно исправить, а таблицы доработать. В ответ не слышу никакой конкретики — снова размытое "результата до сих пор нет".
После такого я спрашиваю у заказчика напрямую, кто несёт ответственность за внедрение разработанных инструментов в его компанию, а также организацию регулярной работы его сотрудников в этих таблицах.
В ответ же слышу, что за это несу ответственность я. И тот факт, что в мои услуги входит только разработка системы и объяснение, как с ней работать, его абсолютно не интересует.
Разбирая каждый случай, я буду подводить краткие итоги: что в обязанности разработчика в данном случае входило, а что — нет.
В данном кейсе я был должен:
Создать систему таблиц, следуя ТЗ, составленному заказчиком;
Проверить работоспособность системы;
Внести правки в соответствии с комментариями заказчика;
Быть готовым к обратной связи и правкам;
Обучить заказчика пользованию созданной системой.
Внедрить систему на производство заказчика;
Протестировать таблицы напрямую в рабочих условиях;
Организовывать работу сотрудников заказчика с таблицами;
Обучить ВСЕХ сотрудников без указания на то от заказчика.
Не стоит перекладывать на разработчика обязанности штатных сотрудников. Специалист никак не относится к бизнесу заказчика, но может сильно помочь в его автоматизации, создавая новые решения.
Случай №2: плохие навыки телепатии
Заказчик обратился ко мне за разработкой системы для его производства, в которой можно было бы планировать заказы, фиксировать смены сотрудников и выполненные ими работы. Также требовалось, чтобы эта система автоматически рассчитывала им зарплаты. Функционала таблиц для озвученных запросов было недостаточно, поэтому решили разработать WEB-приложение.
Так как систему создавали с нуля (ранее всё на производстве считалось "как-то", вручную бригадиром), у заказчика не было точного понимания необходимого функционала на выходе. Поэтому мы договорились на создание самой базовой версии с минимальным функционалом, а также на доработки по мере необходимости, когда станет понятно, что именно потребуется для удобной и оперативной работы сотрудников в системе.
Чрезвычайно важно было сделать такую систему срочно — заказчик даже предложил двойную оплату при условии, что система будет создана не за месяц, а за 10 дней. Благо, сон для слабаков, и мне удалось создать эту систему в короткий срок, чтобы ей быстро начали пользоваться в “полевых условиях”.
За следующий месяц было проведено несколько больших доработок системы, за счёт которых мы добавили функционал для кладовщика, кассу, автоматическое списание расходников и заготовок, а также несколько других моментов. В процессе работы, само собой, появлялись ошибки и недоработки, но все они своевременно исправлялись.
Всё идёт по плану, система используется ежедневно. Заказы создаются, зарплаты рассчитываются, склады ведутся, расходы учитываются. Однако через какое-то время я захожу в эту систему для проверки работоспособности. И вижу, что ею не пользуются уже вторую неделю. Хотя никаких проблем или ошибок за это время озвучено не было.
В этот момент я связываюсь с бригадиром и уточняю, что случилось, и необходима ли помощь с моей стороны. Спустя время бригадир отвечает, что всё в порядке — просто всё это время он был перегружен работой, и у него не было времени фиксировать заказы и смены.
Через несколько дней происходит очередной созвон с заказчиком и его бригадиром, на котором заказчик просит упростить систему, чтобы бригадиру было легче в ней работать, и он успевал её вести. Нюанс следующий: со стороны бригадира никакой обратной связи на этот счёт нет, также нет и никаких предложений. Со слов бригадира, сокращать нечего, потому что все функции необходимы для корректного учёта.
В итоге мы сошлись на том, что уберём этап планирования и дальнейшего утверждения смен бригадиром. Взамен было решено сделать так, чтобы бригадир мог напрямую закрывать смены по факту окончания рабочего дня.
Из-за очереди по заказам я озвучил срок сдачи доработок в неделю. Заказчик очень сильно попросил ускорить этот процесс, поскольку начались конфликты с работниками из-за того, что бригадир не может оперативно рассчитать смены.
В этот момент самое время напомнить, что из-за большой загруженности бригадир не заходил в систему почти 2 недели. Интересно, откуда же тогда появился такой завал и задержка в расчётах ЗП?
Так как я лично знал, что такое бунтующие рабочие на производстве, то пошёл на встречу, и озвученные доработки были готовы за одну ночь. Опять же, сон для слабаков, и порой производственная необходимость вынуждает работать сколько нужно, а не сколько хочется.
Через день мне звонит бригадир и сообщает, что они уже привыкли к планированию, и теперь им неудобно: работники не могут в течение рабочего дня сверять со своих телефонов планы на смену, а бригадир не может через приложение добавлять им работы в течение дня.
Вздохнув, я восстанавливаю обратно прошлую версию кода. К счастью, это не занимает настолько же много времени, насколько это делает написание нового функционала. Да и тестирование новых гипотез — это всегда непредсказуемо, так что абсолютно нормально, что некоторые идеи оказываются неработоспособными на практике.
В связи с тем, что работали мы на тот момент уже достаточно долго и регулярно, я делал для них доработки без предоплаты, время от времени выставляя за них счета, когда они накапливались.
Внезапно, при напоминании об оплате очередного счёта за уже выполненные доработки, я слышу поток упреков: система не работает так, как хочет заказчик, платил он за готовое решение, а не за тестирование и правки, и вообще я только и делаю, что выставляю новые счета за доработки, а нормально ничего так и не работает.
При этом ни со стороны заказчика, ни стороны его бригадира не было озвучено никаких проблем — были мелкие ошибки, но все они уже устранены. Да и возникали эти ошибки только из-за того, что мы регулярно дорабатывали систему, меняя её функционал. Ошибки в процессе отладки новых доработок абсолютно неизбежны.
Само собой, я предлагаю заказчику подробно разобрать проблему, чтобы получить конструктивную обратную связь и отладить конкретные нюансы системы.
Но, увы, во вселенной этого заказчика я, судя по всему, должен обладать сверхвосприятием и читать мысли самого заказчика, его бригадира и сотрудников, чтобы понимать, что именно не так с системой и как сделать её лучше, даже когда мне не указывают на наличие проблем.
Как и в предыдущем случае, наглядно представляю список моих обязанностей для конкретной ситуации. Итак, мне было нужно:
Сформулировать ТЗ вместе с заказчиком;
Разработать WEB-приложение;
Проверить, функционирует ли оно;
На основании обратной связи внести правки;
Провести для заказчика инструктаж по WEB-приложению.
При этом в обязанности не входило:
“Выжимать” обратную связь по приложению;
Сделать всё и сразу без доработок;
Знать все проблемы заказчика с системой без его указаний на них;
Вносить правки на безвозмездной основе, потому что предыдущий вариант внезапно оказался неудобным.
Этот случай — показатель того, как чёткое и понятное ТЗ могло бы значительно облегчить процесс работы как для разработчика, так и для самого заказчика. Впрочем, также важно трезво осознавать свои ожидания от работы специалиста и быть готовым к тому, что не вс получается по щелчку пальца.
Случай №3: ошибочная гипотеза
Заказчица обратилась ко мне за созданием таблицы фиксации "фотографии рабочего дня" каждого бухгалтера её агентства аутсорсинговых услуг. Ключевых целей таблицы было две:
Чтобы каждый бухгалтер ежедневно заполнял отчётность по всем выполненным задачам, указывая клиентов и направления;
Ведение спецификаций на каждого клиента, по которым можно отследить, сколько рабочего времени бухгалтеры тратят на просьбы клиентов, не входящие в пакеты услуг.
К этому заказу также было очень грамотное и проработанное ТЗ — вплоть до формул, по которым должны вычисляться значения в отдельных столбцах.
Таблица была создана и запущена в работу достаточно быстро. Заказчица осталась крайне довольна, поскольку всё работало именно так, как она описала в ТЗ.
Но, спустя месяц-другой, когда эта заказчица снова обратилась ко мне с запросом по работе с другой таблицей, она рассказала, что в итоге первая идея оказалось нерабочей: бухгалтерам неудобно фиксировать все спецификации и сверяться по ним, так как на это уходит очень много рабочего времени. Поэтому той таблицей не пользуются.
Кстати, забавно, что в дальнейшем мы поменялись ролями, и, после открытия ИП я сам стал клиентом в её агентстве.
В этой ситуации речь не идёт о завышенных требованиях к разработчику, поэтому формат вывода касаемо обязанностей будет иной: я расскажу вам, какой результат специалист должен был предоставить, и что произошло даже при выполнении мной всех задач.
Несмотря на то, что для заказчицы я:
Гипотеза не подтвердилась опытом;
Сотрудникам не подошёл формат работы с таблицей;
Фактор времени оказался важнее подробной отчётности.
То, что хорошо в теории, с лёгкостью может не подружиться с практическим применением, и причин тому много: ошибочность гипотез, человеческий фактор, смена приоритетов и т.д. Всё это не говорит о плохом выполнении разработчиком своей задачи — если при сдаче система заказчика устроила, за дальнейший её путь специалист ответственности не несёт.
Случай №4: 50 на 50
Заказчик обратился ко мне за разработкой таблиц для автоматизации процессов на швейном производстве.
Несмотря на то, что не было детального ТЗ, у заказчика было чёткое понимание нужного результата и необходимых процессов для автоматизации, благодаря чему работа шла очень комфортно.
Начали мы с создания системы для планирования заказов и отслеживания графика разработки новых проектов. Причём сам запрос на тот момент был для очень необычным и объёмным. Было интересно погрузиться в эту нишу.
После приёма первой системы заказчик практически беспрерывно начал давать новые заказы на таблицы, поскольку он очень серьёзно занимался автоматизацией своего производства, а также потому, что мне удавалось без проблем реализовывать почти все его пожелания. Это тот случай, когда аппетит приходит во время еды.
За несколько месяцев было автоматизировано множество процессов, и создано несколько крупных таблиц с большим количеством функционала. Но, как потом заказчик упомянул между делом, некоторыми из созданных инструментов они перестали пользоваться, потому что они оказались неудобными для ежедневной работы.
А некоторыми из них, напротив, пользуются каждый день. Например, этот заказчик продолжает время от времени обращаться ко мне по поводу таблицы технолога, в которой создаются технологические карты изделий.
Из-за того, что эта таблица работает за счёт скриптов, время от времени она выходит из строя, когда кто-то из сотрудников по ошибке удаляет важные формулы. Это решается банальным протягиванием формул или восстановлением предыдущей версии таблицы, поэтому, когда этот заказчик звонит и просит посмотреть, почему что-то перестало работать в очередной раз, вопрос решается быстро и без проблем.
Эта ситуация, как и предыдущая, вполне себе адекватная. Она показывает, что результат создания систем одним и тем же разработчиком для одного и того же заказчика может быть совершенно разным.
При разработке всех систем я сделал следующие вещи:
Составил конкретное ТЗ вместе с заказчиком;
В обозначенные сроки выполнил запросы;
Внёс запрашиваемые правки
Обучил заказчика использованию таблиц.
Несмотря на то, что список моих обязанностей не менялся, варианты дальнейшей “жизни” таблиц были следующие:
Таблицы оказались в принципе не нужны;
Ряд систем, хороших в теории, не смог найти применения в ежедневной работе;
Часть таблиц до сих пор используется;
И на некоторые из них по-прежнему поступают заказы на доработку.
Этот случай наглядно показывает, что периодически таблицы становятся непригодными не из-за вины разработчика или заказчика. Иногда такое происходит по воле факторов, не зависящих ни от кого. В такие моменты нельзя утверждать, что кто-то конкретный виноват — ведь вся суть пути в том, чтобы через ошибки понять, что нужно сделать в конкретной ситуации.
О чём говорят эти случаи?
В ряде из них речь шла о завышенных ожиданиях и недосказанностях, а в других заказчики просто осознали, что разработанные для них системы несовместимы с их целями.
Но всех их объединяет одно — разработчик отвечает за процесс создания и тестирования итоговой системы, а также за внесение правок и предоставление финального результата. Он не может прочитать мысли или же предвидеть будущее. Но если обратиться с конкретной проблемой и попросить о помощи, специалист обязательно выполнит свою работу на высшем уровне.
Связь со мной
Другие мои статьи и бесплатные шаблоны таблиц, а также ссылки на сообщества с полезным контентом по таблицам и мои контакты можно найти здесь:
Если вы желаете заказать разработку таблицы с нуля, задать вопросы по возможностям реализации вашей идеи или запросить доработку шаблона, не стесняйтесь обратиться ко мне.
Ну а если в вашей ситуации технических возможностей таблиц будет недостаточно, вы также можете заказать у меня разработку web-сайта или мобильного приложения для автоматизации ваших бизнес-процессов.
