|
Страница 9 из 10
1. Сорванные сроки Ошибка номер один, испокон веков и по сей день преследующая программистов - полное неумение рассчитать временные затраты. Сильно не пугайтесь - все мы оптимисты. Вполне естественно полагать, что реализация проекта займёт ровно столько времени, сколько она должна занять. И ни один сбой в работе не берётся в расчёт. Более того, нам и в голову зачастую не приходит, что у нас могут возникнуть ну хоть какие-нибудь проблемы с реализацией чего-либо. Итак, давайте возьмём себя в руки, подавим этот инстинкт и рассчитаем временные затраты по-другому. Из моей личной практики: когда я берусь за новый проект, я учитываю все факторы, которые только могу вспомнить, оцениваю время для каждого, всё суммирую. Затем полученный результат я удваиваю. Неаккуратно? Я бы так не сказал: заказчики очень довольны, когда вы приносите готовый проект до положенного срока (и наоборот: если вы опаздываете, они совсем не рады этому). Такой "перестраховочный" метод определения временных затрат помогает мне проделать качественную работу по проекту и уложиться в указанные мной сроки. Но, конечно, здесь всё зависит от точности первоначальных расчётов. Каждый программист недооценивает (намного реже - переоценивает) время, необходимое на разработку проекта. При этом каждый имеет свой постоянный коэффициент допуска возможных ошибок. Для меня это 2, для кого-то это 1.5, а у кого-то и все 3. Вся хитрость состоит в том, чтобы найти свой личный коэффициент и впоследствии вносить поправки в расчёты. Недооценка временных затрат на разработку проекта чревато следующими последствиями (слишком хорошо знакомыми мне): - Вы принесёте в жертву проекту всё выше личное время. День и ночь вы будете проводить в работе над проектом, а для отдыха времени не останется (не то чтобы я хочу сказать, что девелоперство это плохо, но программирование в режиме нон-стоп - это невыносимо).
- Вы будете торопиться. Это означает, что вы будете заботиться не столько о читаемости, защищённости и скорости работы проекта, сколько о том, чтобы выложить готовый проект в срок.
- В спешке вы пропустите такие важные этапы, как проверка кода или отладка. Это может не понравиться заказчику и добавить вам работы.
- Может быть, вам придётся прибегнуть к сторонней помощи. Это стоит денег и далеко не всегда помогает (согласно закону Брукса, особенно при разработке капитальных проектов).
Обязательно выделяйте достаточно времени на длительную отладку (столько же, сколько вы выделяете на весь этап кодирования или даже больше) и не менее 1/3 всего времени на планирование. Эти два этапа являются определяющими этапами для всей разработки проекта. SterlingWonderfulToyland.com: Пример Рассмотрим в качестве примера простой проект: сайт SterlingWonderfulToyland.com. Это самый обычный интернет-коммерческий сайт. Его задача - продажа через интернет игровых приставок и видеоигр по сниженным ценам; количество наименований ограничено. Будучи приверженцем старых и проверенных способов продаж, владелец сайта Джон Джузеппе хочет пригласить посетителей зайти на склад и самим выбрать товар. Таким образом, сайт можно логически разделить на две части: - сама система заказов;
- html-часть сайта, приглашающая посетителей зайти на склад и дизайн самого склада.
При планировании я бы составил две отдельные сметы на эти части. Потом бы я сложил два полученных срока, накинул сверху неделю на сборку двух частей и вывалил заказчику конечный срок (для всего сайта, как если бы никакого разделения не было). Html-часть Для простой, статической части сайта я бы взял за основу время, необходимое для вёрстки одной страницы в каком-нибудь редакторе, например Macromedia Dreamweaver(c). И поскольку динамические элементы в данной части отсутствуют, для определения общих временных затрат можно просто перемножить время вёрстки страницы на количество страниц (при условии, что дизайн страниц уже разработан). Затем я бы удвоил полученный результат (поскольку мой личный коэффициент 2). Вообще, этой части не требуется действительно тщательное планирование (посудите сами: дизайнер даёт вам схему того, как всё должно выглядеть, а ваша задача - наверстать страницы в Dreamweaver). Примечание: добавьте ещё интервал примерно с 1/3 всего времени, оно уйдёт на сборку проекта. Например, если вы запланировали разработку скрипта для проверки кредиток за 9 дней, то добавьте ещё 2-3 дня. Система заказов Для динамической части распределение регламента - вещь достаточно сложная. Что может вам здесь помочь - я думаю, это просто разбить задачу на несколько простых составляющих (как, например, операции с кредитными карточками, моментальный заказ за один клик, каталог продуктов, система управления этим каталогом и т. д.) и произвести расчёт без коэффициента. Потом складываю и умножаю сумму на свой личный коэффициент допускаемых ошибок. Только после этого я вычисляю треть времени всей разработки и добавляю её. Всё добавочное время уделяю отладке и тестированию с тем, чтобы предоставить заказчику корректно работающий проект. Примечание: добавьте ещё 1/3 всего времени на планирование, как и в части простого html. Как преподнести такие сроки заказчику То, что вы сумели правильно рассчитать сроки реализации проекта, вовсе не означает, что заказчику они понравятся также как и вам. Иногда, указав слишком большие сроки, вы теряете заказ. Ваши конкуренты дадут более привлекательные сроки лишь для того, чтобы получить этот заказ, а потом просто-напросто не выдержат их. Так что же нужно сделать, чтобы и заказчик был доволен, и вы могли честно выдержать указанные сроки? Здесь наступает момент, когда нужно правильно преподнести заказчику свои услуги и свои сроки... Какие сроки вы можете предложить? Что делает ваши сроки выполнимыми и почему поставлен именно такой срок, а не какой-либо другой? Нередко помогает мысленный разговор с заказчиком: представьте себя на его месте и подумайте, чего было бы справедливо ожидать от потенциального исполнителя заказа? Вот некоторые из аспектов, которые показались мне наиболее важными: - Делайте качественную работу. Другие могут выполнить работу немного быстрее вас, но ваш козырь в том, что вы сделаете всё правильно и корректно, что, в конечном счете, сэкономит заказчику время и деньги (особенно сильный аргумент, если вы получаете почасовую оплату).
- Выдерживайте сроки. Вы даёте сроки и собираетесь выдержать их. Другие могут дать более привлекательные сроки, но далеко не собираются их выдерживать.
- Предоставьте рекомендации. Ваши предыдущие проекты говорят сами за себя. Соберите с ваших довольных заказчиков различные отзывы и рекомендательные письма с тем, чтобы впоследствии предъявить их потенциальному начальнику/заказчику.
- Будьте тщательны! Проверьте орфографию и грамматику во всех ваших выкладках. Добавьте схемы и графики, подробно и ясно опишите всё, что вы планируете сделать и сколько времени займёт выполнение каждой из поставленных задач.
- Предлагайте несколько вариантов. Не ограничивайтесь простым заявлением о том, сколько времени, по вашему мнению, займёт выполнение какой-либо задачи. Дайте несколько возможных вариантов. Как будут развиваться события по самому оптимистичному сценарию? А как по самому пессимистичному?
- Указывайте наикратчайшие возможные сроки. Чем больше срок выполнения, тем больше вероятность того, что он не будет выдержан.
Если вы всё же указали слишком короткие сроки Если же подобная неприятность всё же случилась и вы, мягко скажем, не успеваете, у вас всё ещё есть несколько возможных вариантов действий (о которых не очень часто вспоминают в подобных ситуациях): - Поддерживайте связь! Постоянная связь программиста с заказчиком - вряд ли можно придумать что-либо важнее. Постоянно информируйте заказчика о том, что вы в данный момент делаете по проекту. Если вдруг вам понадобится увеличить срок, сделать это будет намного легче, чем, если бы от вас всё это время не было никаких новостей.
- Продемонстрируйте заказчику/начальнику готовую часть сайта. Демонстрация уже сделанной работы нередко облегчает вам переговоры по выделению дополнительного времени. Покажите, что вы работаете над проектом.
- Найдите стрелочника. Возьмите всю ответственность за опоздание на себя, но не забудьте указать различные внешние факторы, помешавшие выполнить заказ в срок.
- Срезайте углы. Это отвратительно и неприятно, но если вы действительно не укладываетесь, придётся срезать несколько углов и выдать заказчику рабочую версию продукта с подробным списком всех багов. Потом, во время тестирования или позже вы вернётесь к ним и исправите.
- WYSIWYG. При работе над web-проектами я предпочитаю писать html-код руками, ибо очень не доверяю графическим html-кодерам. Однако если ваш проект трещит, то стоит рассмотреть и такой вариант.
|