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

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

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

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

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

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

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

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

• Создать систему таблиц, следуя ТЗ, составленному заказчиком;

• Проверить работоспособность системы; 

• Внести правки в соответствии с комментариями заказчика;

• Быть готовым к обратной связи и правкам;

• Обучить заказчика пользованию созданной системой.

И НЕ должен:

• Внедрить систему на производство заказчика;

• Протестировать таблицы напрямую в рабочих условиях;

• Организовывать работу сотрудников заказчика с таблицами;

• Обучить ВСЕХ сотрудников без указания на то от заказчика.

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

Случай №2: плохие навыки телепатии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сформулировать ТЗ вместе с заказчиком;

• Разработать WEB-приложение; 

• Проверить, функционирует ли оно; 

• На основании обратной связи внести правки;

• Провести для заказчика инструктаж по WEB-приложению.

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

• “Выжимать” обратную связь по приложению;

• Сделать всё и сразу без доработок;

• Знать все проблемы заказчика с системой без его указаний на них;

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

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

Случай №3: ошибочная гипотеза

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

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

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

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

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

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

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

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

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

• Создал таблицу в соответствии с её ТЗ;

• Протестировал её на возможность использования;

• Внёс полученные правки,

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

• Гипотеза не подтвердилась опытом;

• Сотрудникам не подошёл формат работы с таблицей;

• Фактор времени оказался важнее подробной отчётности.

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

Случай №4: 50 на 50

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

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

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

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

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

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

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

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

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

• Составил конкретное ТЗ вместе с заказчиком;

• В обозначенные сроки выполнил запросы;

• Внёс запрашиваемые правки

• Обучил заказчика использованию таблиц.

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

• Таблицы оказались в принципе не нужны;

• Ряд систем, хороших в теории, не смог найти применения в ежедневной работе;

• Часть таблиц до сих пор используется;

• И на некоторые из них по-прежнему поступают заказы на доработку.

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

О чём говорят эти случаи?

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

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

Связь со мной

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

taplink.cc/drobnitsavladimir

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

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

К сожалению, программист игнорировал это ТЗ в 80% случаев: делал, судя по всему, “из головы” и отправлял мне на проверки. Я перепроверял весь материал, давал обратную связь, объяснял, что именно не так и отправлял ему на корректировку. И так почти каждый день. Полноценно работающей оказалось только 52-ая версия проекта.

Больше 50-ти версий... Даже звучит как-то нереалистично.

И каков результат?

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

Но не всё было так гладко…

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

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

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

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

Новые поиски

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

В процессе поиска пришлось перебрать множество предложений от разных компаний и фрилансеров. В какой-то момент на одной из крупных фриланс-площадок я нашёл исполнителя, который специализировался как раз на переносе таблиц в формат WEB-сайтов. Бонусом стала адекватная цена услуги — всего 25’000 рублей.

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

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

Программист-опоздун. Снова некомпетентный

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

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

Через месяц, когда система была готова на 90%, оказалось, что этот специалист никак не мог разобраться с одним из ключевых требований — с выведением остатка в кассе.

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

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

Компетентный программист

Однажды, из личного любопытства, я решил попробовать сделать для себя небольшого голосового помощника, который мог бы работать по скрипту. Идея следующая: сделать искусственную замену психотерапевту, благодаря которой можно было бы получать тот же эффект от сеансов, не отдавая по 7’000 рублей в час.

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

(Перечитывая текст, понимаю, что у меня очевидно наличие какой-то нездоровой тяги к поиску программистов и созданию новых систем и инструментов, независимо от их назначения)

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

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

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

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

Внезапно, не самый удобный формат

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

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

Похожий кейс, но с некомпетентным программистом

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

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

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

А какой здесь вывод?

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

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

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

Связь со мной

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

taplink.cc/drobnitsavladimir

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

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

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

Создание таблицы

Обсудив запрос, мы обозначили тз — сделать удобную систему в формате таблиц.

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

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

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

Ожидание/реальность

Казалось бы, всё замечательно: заказ выполнен, система функционирует, все рады. Но вот наступает начало сезона.

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

К чему привёл этот “небольшой” момент?

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

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

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

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

Решение — специальный мини-сайт!

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

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

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

В чём же связь таблицы и сайта? Неужели вся проделанная работа была насмарку? Совсем нет!

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

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

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

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

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

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

Связь со мной

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

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

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

taplink.cc/drobnitsavladimir

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

Должен признаться, что примерно 10 лет назад, у нас была ситуация, когда почти 3 года подряд, у нас не было своих разработчиков, а были только менеджеры и 2 php-тимлида. И мы умудрялись выполнять не только проектную работу, но и отгружать более 1000 часов в месяц нашим клиентам по поддержке сайтов. Да, это было тяжелое время, и менеджеры горели в прямом смысле этого слова, т.к. отвечать за действия чужих аутсорс-команд гораздо тяжелее, чем работать со своими родными разрабами.

Сейчас у нас практически все делается штатными спецами, и это конечно нереальный кайф и свобода. Но сейчас у нас и проекты сложнее, и ожидания клиентов выше. В основном это комплексные проекты, где разработка является только частью всего процесса, и нашим менеджерам приходится выходить на уровень стратегов и бизнес-аналитиков, чтобы управлять такими проектами. И некоторые вообще переходят в новую роль. Так, в этом году у нас буквально "родился" отдел аналитики, который сформировался из проектного менеджера, который стал продактом, и SEO-специалиста, которая стала бизнес-аналитиком и digital-стратегом.

А где таких умничек брать, спросите вы? Есть 2 пути — воспитывать и растить, или брать с рынка. Мы используем оба метода. К примеру, оказалось, что из тестировщиков сайтов за полгода-год может получиться довольно крепкий проджект разработки, а из SEO-шника стратег. Но если года в запасе нет, то приходится "выходить на рынок", и искать ребят, готовых приступить здесь и сейчас.

Срочно пишите мне, если вы кайфуете от управления проектами как и мы!