Меню

Eremeev Group / News

Строим сайты, пишем программы, занимаемся продвижением

«Воспитательная работа», которая убьет ваш проект

Крепостное право в России отменили в 1861 году. В 1863 году открылась первая ветка лондонского метро. Эти две даты в совокупности демонстрируют днище в договороспособности нашего контингента и некоторое отсутствие самоуважения. В чем это все проявляется? Например, отношение «я начальник — ты дурак» проходят как в классическом режиме найма, так и в контрактных взаимоотношениях. Начинается все с того, что разработчик заранее соглашается с нереальными (или близким к нереальным) сроками сдачи этапов. Соглашается, хотя и клиент и разработчик отлично понимают, что озвученные  сроки будут безбожно про… сорваны. Конечно, если перед работами будет составлено подробное техзадание и разработчик «вопрётся» в задачу на фуллтайм, то все или почти все будет сделано вовремя. Но нормальных техзаданий не любят клиенты.
Почему не любят? Очень просто: ТЗ может разрабатываться неделю, две, месяц, а клиенту хочется с первого дня начать “рисовать дизайн” и вообще — документы это просто скучно. Клиент даже может услышать где-то слово agile («аджайл») и говорить, что у него все по agile. Да, agile позволяет сделать нечто, показать клиенту, а потом перерабатывать, но такая работа сразу отодвигает за горизонт понятие готового продукта, так как и клиент и разработчик не понимают, чем все кончится. А если такого понимания нет, то здесь лучше договариваться на помесячную оплату работ и нечеткий график сдачи этапов.

Следом начинается фактор оплаты. Выставленный счет на предоплату первого этапа может проболтаться в бухгалтерии заказчика месяц, два или еще сколько-то, в зависимости от приоритета проекта. «Ну вы стартуйте, деньги скоро будут», после чего разработчик (или команда разработчиков) делают продукт, основываясь на честном слове. А для недопущения кассового разрыва (зарплаты, офис, прочие расходы) разработчиком может быть взято N параллельных проектов разной степени замороченности и разных бюджетов, что может повлиять на срок разработки того самого проекта, по которому вроде бы шла работа и вроде бы были оплаты. В итоге, в определенный момент деньги за первый этап все же приходят, но не все и/или невовремя. Естественно, следующий этап будет невозбранно задержан, несмотря на наконец-то сделанную оплату. Вместо того, чтобы простимулировать работы хотя бы своевременной оплатой, за задержку работ оплата будет также по N причинам задержана: «вы обещали все сделать за месяц, а провозились три» (при этом совершенно не учитывается задержка аванса, нежелание формализовать задачу в виде подробного техзадания и т.д.).

Естественно, нормальный разработчик до определенного момента будет пробовать спасти ситуацию, делая требуемые клиентом доработки и ожидая оплат, но долго это продолжаться не может. В некоторых ситуациях, видя, что способ «воспитательной работы» вроде бы действует («мы этим дебилам не платим, а они делают всё, что говорим»), заказчик уходит за грань адеквата и требует выполнения ранее не оговоренных задач. Одна задача, вторая, неделя задержки оплаты, вторая… и разработчик просто перестанет реагировать, находя законные способы выйти из проекта. Одним из оправданий (если дело дойдет до суда) будет та самая задержка оплаты. А если таких задержек или вовсе неоплат несколько, о чем вообще речь?

Что в итоге?
Варианты:
— проект закроют;
— передадут другим разработчикам (которые тоже пообещают волшебство);

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

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

И все же, иногда мы работаем бесплатно или почти бесплатно. Когда нарабатываем портфолио, когда давно знаем клиента, когда помимо денег получаем брендового клиента, который поднимает наш статус под небеса. Или когда сами делаем собственные инвестиционные продукты, уже для себя. Но в этих историях всегда важен work/life баланс и понимание финвопроса. Как со стороны заказчика, так и со стороны исполнителя.

В ближайших выпусках выйдет статья «Работаем по уму». Если будет соблюдено хотя бы 50% из описанного — ваш проект спасён!

А теперь — ещё немного философии. С одной стороны, мы дети и внуки героев, которые не раз прогоняли всяких уродов с нашей земли. А с другой – мы же потомки холопов и самодуров. Мы можем в стрессе и напряге решать проблемы мирового масштаба. Прогнать фашистов, построить БАМ или запустить Гагарина в космос. Но когда надо грамотно распланировать сроки задач, рассчитать поток финансов и учитывать ресурсы — наш «типаж» дает сбой. Над этим можно и нужно усердно работать, выживая из себя ущербную психологию. Тесто, из которого сделан барин-самодур и вечно оправдывающийся холоп, вполне можно перемесить и начать наводить порядок, начиная с себя. Так мы вместе добьемся успеха.

Если ты заказчик, у тебя нет денег, но проект нужен – скажи сразу, не дури с оплатой аванса и задержками платежей «в воспитательных целях». Всегда можно найти разработчика, озвучить ситуацию и поискать выходы. Разумную постоплату также никто не отменял, но она должна быть в договоре, а не по факту в виде задержек. То же самое и к исполнителю: проработай свои бизнес-процессы, пиши техзадания, рисуй макеты, утверждай под расписку у клиента каждый этап работы и не двигайся без оплаты ни на сантиметр. Озвучивай причины остановки «где бабло бля?», а не занимайся вежливыми оправданиями «скоро всё будет готово», в то время, как истерящему «когда все будет готово?!» клиенту клиенту весьма начихать на то, что едят твои программисты и дизайнеры.

Добавить комментарий