Как облажаться, верно сделав задачу
Я уверен, что каждый, кто связан с разработкой программного обеспечения, хотя бы раз сталкивался с ситуацией, когда задача выполнена правильно, но заказчик остаётся недовольным. Разработчик считает, что заказчик придирается или просто не хочет платить, а заказчик думает, что разработчик тупой или не хочет работать. Однако в большинстве подобных случаев, которые я наблюдал, причина проблемы была в том, что разработчики выполнили задачу, но не помогли заказчику достичь его целей. Оставим вопрос о том, кто прав, а кто виноват, и попробуем разобраться, как можно облажаться, выполнив задачу верно.
Вообще в любом деле способов сделать что-то неправильно всегда больше, чем способов сделать правильно. Но для себя я выделил несколько самых распространённых причин, по которым верно сделанная задача не способствует достижению цели.
Дорога ложка к обеду
Есть задачи, решение которых приносит пользу только если они выполняются к определённому сроку. Типичный пример — праздничная акция. Скажем, ко Дню защитника Отечества надо добавить на сайт некоторую функциональность. Цель задачи ясна — получить дополнительную прибыль. Но если задача не будет сделана 22 февраля, то подобно карете Золушки, ровно в полночь затраченные на выполнение задачи ресурсы волшебным образом превратятся из вложений в убытки и упущенную выгоду. Задача сделана, всё работает правильно, но уже на фиг никому не нужно.
Думаю, тут даже примеры приводить не надо, все с такими случаями сталкивались.
Что ты мне дал, то я и перепутал
Пожалуй, самая распространённая причина.
Суть её в том, что исполнитель скрупулёзно делает задачу, но не задумывается о том, для чего она нужна. В итоге может получиться так, что всё было сделано как просили, но это опять таки никому не нужно.
Случай из жизни: статистика по клиентам
Отдел маркетинга решил проанализировать поведение клиентов и для этого отделу разработки была поставлена задача по сбору статистики. Было написано какие события клиентского пути надо фиксировать. Около двух недель ушло на разработку и месяц собирали статистику.
Увы, из-за отсутствия в организации единого языка программисты и маркетологи по-разному понимали слово «клиент». Для программистов клиент — это пользователь, для которого создана учётная запись. Для маркетологов — человек, с которым заключён договор.
В итоге все собранные данные оказались бесполезны, т. к. отражали совсем не то, что было интересно маркетологам. Полтора месяца было потрачено зря.
И только когда это выяснилось, маркетологи рассказали, что статистика была нужна статистика для проверки определённой гипотезы. Если бы разработчики изначально знали эту цель, а не просто слепо выполняли задачу, у них была бы возможность понять, что собирать надо совсем другие данные.
Случай из жизни: комиссия по банковской карте
Команде была поставлена задача: при оплате банковской картой надо начать взимать комиссию.
Аналитики определили, что взимание комиссии должно быть прописано в договоре. Поэтому взимать её можно только по новым договорам, а по старым надо всё оставить как было.
Система была построена так, что подсистема платежей не имела доступа к договорам и не могла проверить — старый договор у клиента или новый. Изменение этого потребовало значительной переделки. Суммарно аналитика с разработкой растянулись примерно на месяц.
Через месяц директор на планёрке поинтересовался: почему комиссия до сих пор не взимается? Когда ему рассказали об описанных выше проблемах, директор много ругался. Содержательная часть его монолога сводилась к тому, что: а) каждый день, пока не взимается комиссия, компания недополучает значительную сумму (пусть это будет 50 000 рублей); б) срок 99 % договоров не превышает 30 дней, а значит если бы месяц назад начали заключать договоры по новой форме, то сейчас в 99 % договоров комиссия уже была бы; в) самое страшное, что грозит компании, если она возьмёт комиссию по старому договору, это штраф, не превышающий 5 % от ожидаемого дохода с комиссии.
Понимая исходную цель (сократить период в течение которого компания недополучает прибыть от комиссии), можно было бы совсем иначе выполнить поставленную задачу.
Случай из жизни: сбор пользовательских согласий
Разработчикам была поставлена задача — надо собирать и сохранять согласия пользователей (на обработку персональных данных, на получение рассылок и т. п.). Причём целью было заявлено именно сохранение согласий. Были поставлены задачи, часть которых даже была выполнена.
К этому времени у меня уже был опыт работы с подобными согласиями и я смог заподозрить неладное. Применив метод 5 «для чего?» удалось выяснить:
цель заказчика — избежать штрафа за неправомерные действия (например, рассылку);
для этого нужна возможность найти данное пользователем согласие по его реквизитам (ФИО, телефон, e-mail).
Т. е. сохранить согласия мало. Важно их потом найти. Но предусмотренный и уже сделанный к этому времени поиск как раз по нужным данным искать и не позволял. Таким образом верно (в соответствии с проектным заданием) сделанная задача могла оказаться бесполезной, когда через несколько месяцев или год понадобилось бы найти согласие, чтобы избежать штрафа.
Я свою часть сделал!
Пожалуй, самая тупая из всех известных мне причин.
Заключается в том, что исполнитель замыкается только на своей части работ и не думает о том, как эта часть должна служить достижению общей цели.
План
Добавить примеры «Я свою часть сделал!…
тестирование;
интеграция;
обновление существующих данных в БД (миграция с добавлением полей).