Техническое задание на разработку программного обеспечения (ПО) — это неотъемлемая часть работ, которая производится чаще всего заказчиком программного обеспечения, для формулирования всех функций, которое это ПО должно выполнять. Под программным обеспечением в данном случае понимается и приложение под Windows или другую операционную систему, и приложение под мобильные системы, такие как Android и iOS, а также это может быть целый сайт или скрипт.
На фрилансе техническое задание на разработку программного обеспечения (ТЗ) передается непосредственно перед началом работы. Это касается ТЗ по всем видам работ, но в данной статье я в частности буду рассматривать работу программиста. Перед началом работы программист оценивает объем работ, в соответствии с объемом определят временные затраты которые предстоят, определяет бюджет и озвучивает его заказчику. Если бюджет заказчика устраивает, то можно сказать что сделка считается состоявшей и программист начинает работу. Финансовые аспекты работы на фрилансе рассмотрены в моей другой статье.
Что же происходит дальше? Программист усердно работает, делает все согласно технического задания, создает приложение, тестирует и отлаживает его. И вот приложение готово и он с радостью передает его заказчику. Его ожидания: заказчик посмотрит работу, оценит ее по достоинству, скажет спасибо и осуществит окончательный расчет.
Но что же происходит на самом деле?
Все происходящее далее можно разделить на три варианта:
1. Идеальный. Заказчику все нравится. Вы получаете оплату и расстаетесь. Довольны оба. Для работы программиста случай практически не встречающийся на практике. Я бы сказал, что на него приходится не больше 5% от всех завершенных заказов.
2. Заказчик обнаруживает, что часть функционала, описанная в техническом задании, реализована неверно или работает не так как надо (с ошибкой). Здесь справедливым будет факт того, что программист некачественно выполнил свою работу. И, наверное, все согласятся, что со стороны программиста самым верным решением будет, то что работу необходимо доделать.
3. Заказчик смотрит на работу и понимает, что по ТЗ все сделано, но он сам не учел некоторые моменты, которые ему необходимы для работы. Например, по ТЗ программа должна формировать таблицу в формате Excel, но при этом заказчик забыл указать, что данная таблица после формирования должна автоматически отправляться на e-mail адреса его клиентов. Да, действительно ситуация для него не очень приятная. И тут начинается самое интересное: он просит программиста сделать доработки в рамках уже существующего бюджета. Мол работы же совсем не много. Можно и сделать.
Для упрощения — таксисты
И вот тут в мое повествование входят таксисты. Представьте себе такой сюжет: вы заказали такси скажем с ресторана до дому. Изначально с оператором обговорили цену. Сколько будет стоить поездка до Вашего дома. Пока ждали такси, к Вам подошел друг, с которым Вы сидели в ресторане и попросил поехать вместе. Т.е. фактически для таксиста это означает поездку с заездом в дополнительную точку. И в данном случае ни у кого не придет в голову, что таксиста можно попросить совершить поездку за те же деньги. Так почему же так можно делать с программистами за выполнение работы, не входящей в техническое задание?
В том случае, если со мной возникает данная ситуация, я поступаю следующим образом: если доработка действительно небольшая (до 15 минут), то иду навстречу и делаю. Если дольше, то сразу говорю заказчику, что эта работа не входила техническое задание и ее можно выполнить в рамках отдельного бюджета после завершения текущих работ. Если это сказано сразу, то далее вопросов никаких не возникает и в ряде случаев со стороны заказчика появляется уважение и понимание, что я как специалист ценю свою работу и заставляю ценить ее других людей.
Эта статья написана как для заказчиков, так и для исполнителей. Цените свою работу и уважайте работу других.
Татьяна
Супер! Отличная статья