Любимые административные грабли интернетчика
Вторая серия, начинать читать можно тут.
Пару недель назад меня пригласили почитать что-то полезное на секции разработчиков на конференции Digital Оттепель в Нижнем Новогороде. Времени было очень мало и я накидал любимые организационные грабли, по которым скачут 90% интернет-компаний, которых мне доводилось консультировать. Конечно, есть шанс, что мне просто везло. Но я что-то мало верю в такое роковое везение на разные города и разные масштабы.
В итоге наковырял некоторую пачку, с которой и предлагаю поиграть в Капитана Очевидность
Доблестно отчитавшись, я засел беседовать с подтягивающимися из зала парнями, и по ходу беседы услышал от одного из них, что мое выступление было про то, что надо реально все затащить в договор. Это было чертовски неожиданно, надо заметить.
Ну, то есть, да. Поскольку практически все проблемы, о которых я говорил, были административные, то и решать я их предлагал административно. А это подразумевает дополнение типового договора. Суть в том, что я в какой-то момент настолько взял на себя парадигму поведения «ВСЕ, что надо делать — опиши через договор», что прогоняю этот момент через разговор автоматом, не фиксируясь на нем вообще.
Казалось бы, я сейчас подогнал большой тезис ПРОТИВ автоматизации договорной работы. Я же сам грязными ручонками лезу в текст.
И так, и не так.
Некоторая прелесть автоматизации в том, что она позволяет практические приемы перевернуть в юридически организованную плоскость, не вынуждая потребителя задумываться «а как бы это описать в правильных терминах». Давайте пробежимся по тем граблям, которые я особенно люблю. И, коли уж пошла такая пьянка, я не отказался бы еще от чего-то хитрого; приходите в комменты.
1. Работа до подписания договора.
Это вполне известный нюанс, про него даже в прошлый раз мне писали коммент «а на хрена начинать работать до договора». Коммент от человека не из отрасли, как понятно. История, когда заказчик готов переслать предоплату сразу, а вот договор у него согласуется долго, очень распространена. И случаются очень досадные неожиданности.
Решение: описывать в договоре договорный период как специфику контракта и описывать ситуацию, когда договоренности до подписания и зафиксированные в договоре — расходятся. В идеале неплохо бы ранние договоренности тоже фиксировать в недоговорной форме, меморандумами, например. Основной смысл в том, чтобы подписанный договор не отменял любые ранние договоренности, как происходит по дефолту, а подтверждал их существование.
2. Внезапные изменения ТЗ.
Как известно, ТЗ — это не только техзадание, это еще Точка Зрения, и она может меняться. Вспоминаем мою любимую открытку на тему.
Примите на себя новую парадигму — изменения ТЗ не являются проблемой, если они оплачены. Как любил говорить я в период, когда мы делали много сайтов «это не проблема, это — бюджет». Закладывайте в смету управление требованиями (и вообще, приучайтесь называть ТЗ требованием, как взрослые), описывайте формулу, сколько надо будет доплатить за тот или иной масштаб изменений, причем некоторый разумный изначально заложите. И, собственно, нет проблем. На вопрос «а почему мы должны доплатить» вы ткнете пальцем в договор, и будет вам счастье или разрыв контракта. Причем последнее — еще большее счастье, если присмотреться к раскладу.
То же самое относится к переработкам.
3. Переработки.
Закладывая в договор переработки изначально, вы лишаете ситуацию внезапности этих переработок. А именно внезапность обычно является камнем преткновения. Особенно это стреляет на мелочах.
Когда внезапно возникает необходимость все к чертовой матери переделать, по какой-то внезапной причине, — это большая проблема, и заказчик обычно способен это осознать. Ну потому как это БОЛЬШОЕ. А вот мелкая фигня, которую потеряли при раннем планировании, но которую надо бы сделать, потому как без нее фигня получается — она такого понимания не вызывает. Ну там же работы на полчаса. ОК, час. И мы же уже три такие сделали на той неделе, и никаких разговоров о деньгах не шло. С хрена ли сегодня?
Та же методика — во-первых, с самого начала закладываем 10% производственного бюджета на переработки. Они же точно будут, мы в курсе. Только это надо сделать не молча задрав бюджет на 10%, а описав это отдельно и пообещать вернуть, если вдруг их не будет. Все мы понимаем, что шансов на такой поворот почти нет. И дальше там же писать: заложено, предположим, семь часов, чтобы начался восьмой час, надо предоплатить следующие 10%. Иначе никак. И по ходу работ не забываем ПИСЬМЕННО извещать об идущих переработках.
Такой подход дает двойную предсказуемость для клиента. Во-первых, он заранее знает, что переработки бывают, что они платные и что они считаются в тех единицах, что у вас записано. Во-вторых, на момент выставления счета он уже имеет опыт наблюдения за доработками и тем, как расходуются на них деньги, а значит, имеет возможность заранее прикинуть, как будет израсходован (или нет) следующий взнос.
4. Сроки, слетающие по вине клиента.
99% клиентов недооценивают, насколько долго они будут готовить для вас материалы, сколько времени займет обсуждение каждой итерации и так далее, и тому подобное. В итоге сроки сдвигаются, а претензии все равно предъявляются исполнителю.
Рациональным способом является полноценный регламент работы с документами при вашей работе с заказчиком. То есть, иногда пункт про то, что задержки возникшие по вине заказчика добавляются к срокам контракта, прокатывает. Но это все равно тонкая материя. А вот регламент — то штука безусловная. Прописывайте правила. Причем, прописывайте их разумно. Если вы напишете, что заказчик ОБЯЗАН отвечать в течение 24 часов, то это не только не будет работать, но и вероятнее всего не подпишется. А вот разумное требование, чтобы заказчик извещал вас после получения запроса на материал или согласование, к какому дню и часу он даст ответ, обычно находит понимание. Приложив к этому таблицу о нормативах переносов сроков, в зависимости от скорости поступления ответов, мы получаем отличный калькулятор сроков, которым легко пользоваться и к которому легко апеллировать.
Вот такие 4 типичные проблемы. В лекции их было пять, потому как пятая была связана с приемкой креатива. Но это уже беда, которую невозможно качественно разрулить административно, посему в сегодняшний текст не входит.
Все 4 заявленных темы достаточно легко алгоритмизируются, а значит, подлежат включению в автоматизацию. Повторю свой вопрос: какие еще организационные проблемы с сайтостроением вы отлавливаете у себя? Поделитесь и через некоторое время у нас с вами будет отличный Хитрый Договор.
© Megamozg
