Страница 10 из 19
Стоимость исправления ошибки на ранней стадии несоизмеримо ниже, чем на поздних стадиях проекта. Особенно это четко прослеживается на этапе выработки требований и составления ТЗ. Если вы заложите какое-то неверное требование, то исправить эту ошибку перед началом работы над сайтом не составляет труда. Однако, чем дальше вы будете продвигаться по проекту, тем больше будет стоимость исправления этой ошибки.
Приведу пример: допустим, вы решили сделать дизайн с фиксированной шириной в 1000px (наиболее распространенный вариант на сегодня). Вы утвердили все ТЗ, дизайнер сделал макет, вы его утвердили. На данный момент стоимость исправления этой ошибки возросла, но не сильно, т.к. при исправлении придется только оплатить дизайнеру доработки макета страниц сайта.
В случае если сайт уже сделан разработчиками и макет сверстан, то стоимость еще возрастает, поскольку придется делать доработки на нескольких уровнях – дизайн, верстка, возможно JS программирование.
Допустим, сайт уже работает пару лет, и вы решили изменить это требование, например, уменьшить ширину до 900px. Тогда цена исправления становится еще больше, т.к. после исправления необходимо весь сайт протестировать на предмет проблемы с корректным выводом контента.
Ошибки надо исправлять на ранней стадии.
Делайте свои проверки регулярными и по четким метрикам. У вас может быть свой набор метрик. В случае проблем выясняйте причину и, что более важно, как поставщик будет ее решать.
Примечание. По возможности не меняйте поставщиков на время проекта. Это довольно негативно сказывается на качестве проекта и на его конечной цене. Прибегайте к этому только в крайнем случае, когда остальные методы воздействия уже не срабатывают. Надеюсь, что вам это не понадобится, поскольку мы довольно скрупулезно подошли к выбору поставщиков.
Также хорошим приемом обращения с поставщиками является брать с них некоторые личные обещания. Это подстегивает их делать работу в срок, поскольку невыполнение обещаний негативно влияет на репутацию. Но при этом помните, что если вы выдавливаете из поставщика нереальный срок исполнения и обещание сделать задачу к заданному сроку – вы тем самым подрываете ваши взаимоотношения и весь проект в целом. Делайте это очень осторожно и в умеренных дозах.
Взаимодействие для экстремалов
Если у вас довольно много проектов, и вы имеете хорошую команду, то можете попробовать совместить закон Паркинсона и закон Парето.
Закон Паркинсона гласит, что работа заполняет все отведенное ей время.
Закон Парето говорит нам о том, что 80% всей важной работы выполняется 20% сотрудников.
Есть много вариаций на тему этих законов, но для нас сейчас важно не это. Одним из советов Стива Джобса по разработке было: “Разрабатывайте рывками. Делайте за месяц то, что в обычном планировании может занять полгода”.
Закон Паркинсона + Закон Парето = небольшое технологическое чудо
Вы можете попробовать этот подход. Запланируйте под определенный проект максимально краткий срок. Тут конечно есть множество ограничений, и с этим надо экспериментировать, прежде чем внедрять в большой проект. Если вы это примените к части некоторого большого проекта, то в итоге это может сильно повысить риски выхода всего проекта за рамки времени и бюджета. Это возможно провернуть только с проверенной командой, которая знает правила игры. И эти люди должны быть из первых 20%, т.е. это должны быть самые эффективные профессионалы в своих областях.
Итерационная модель взаимодействия по проекту.
Сразу скажу, что это наиболее жизнеспособная модель, которая подойдет большинству проектов.
В чем ее смысл? Вы организуете работу над проектом в виде итераций. Конечно, это в большей мере относится к программной разработке. Вы разбиваете проект на несколько частей.
В первой части вы реализуете основной каркас приложения, базовые функции. Тем самым вы обеспечиваете себе некоторый результат на ранней стадии разработки и можете начать работать над заполнением сайта контентом буквально через неделю после начала проекта.
На последующих итерациях вам необходимо будет дорабатывать другие, менее важные модули, которые, тем не менее, необходимы для успешного достижения целей сайта (надеюсь, вы о них помните).
В чем плюсы такого подхода?
● Вы получаете работающий функционал на ранних этапах
● Гораздо легче осуществлять контроль над ходом разработки сайта
● Планирование упрощается за счет того, что вы в конкретный момент времени думаете только о текущей итерации.
● Такой подход повышает доверие между заказчиком и поставщиком. Малые итерации на начальном этапе взаимодействия позволяют установить доверительные отношения быстрее, чем это делается в традиционном подходе, когда весь проект делается весь сразу и также сдается.
● Вы можете исправить ошибку на ранних итерациях, а это, как вы помните, обходится дешевле, нежели исправления на завершающих стадиях. Очень часто бывает так, что заказчик, начав пользоваться продуктом, понимает, что надо внести коррективы в требования, поэтому, чем раньше он получит доступ к сайту, тем лучше это будет для всех.
А минусы? Честно говоря, любой минус, который мне приходит в голову, меняется на плюс. Например, можно было бы сказать, что необходимо дополнительно планировать разбиение функционала на итерации, т.е. фактически выполнять дополнительную работу. Однако это позволяет вам определиться в своих приоритетах. Какая функция наиболее важная? Что мы можем отложить на потом? А что мы можем вообще не делать?
Сразу хочу сказать, что этот подход имеет место для средних и крупных проектов. В малых проектах весь функционал можно реализовать за одну итерацию. Однако для любого проекта необходима раскрутка. И опять же итерационный подход может вам реально помочь. Вы можете совместно спланировать со специалистами по SEO вехи, которые вы должны пройти при продвижении сайта в поисковых системах.
А ТЗ?
При участии в проекте следует чаще обращаться к главному документу разработки – техническому заданию (ТЗ). Вы можете в электронном виде ТЗ помечать маркером, что выполнено, что находится под вопросом и т.д. При этом вы можете использовать следующую цветовую легенду: зеленый – выполнено, красный – выполнено, но с ошибками, желтый – требует обсуждения.
Как только весь файл ТЗ приобретет зеленый цвет – можно сказать, что вы закрыли все требования по ТЗ.
Также хотелось бы вам порекомендовать использовать Google Disk (или Google Docs – старое название системы). Этот сервис позволяет организовать групповую работу над документами: электронные таблицы, текст, диаграммы, формы.
По сути это очень сильно напоминает MS Office, однако имеет ряд преимуществ:
● позволяет командную работу над документом