“Дьявол находится в мелочах” или несколько советов по работе с ТЗ
Отличительное качество настоящего профессионала — это признание того факта, что “дьявол находится в мелочах”. Мелочи решают вопрос об успехе или поражении, и так было всегда.
Брайан Трейси “Эффективные методики продаж”.
Оглядываясь на свой опыт работы программистом с различными проектами могу сказать точно, что в техническом задании (далее и везде - ТЗ) ДЕТАЛИ и МЕЛОЧИ могут оказаться важнее общей направленности разработки. Это вполне логично: разработок, которые отличаются по своей “сущности” не так уж и много. И практикующий программист сталкивается с большей частью из них. По большому счету, все что разрабатывается можно свести к десятке обобщенных моделей и их пересечений. А вот конкретный проект как раз и состоит - из ДЕТАЛЕЙ, которую эту модель уточняют.
Возьмем, пример. Мне часто попадают в руки проекты различных парсеров. Парсер/граббер - типичная модель. Нам нужно откуда-то получить информацию и что-то с ней сделать. А дальше начинаются уточнения: откуда и какую информацию нужно получить? нужно это сделать один раз или переодически? собираем информацию и обрабатываем ее сразу или сначала сохраняем в базу, а базу обрабатываем отдельным процессом?… И так далее.
Еще одна типичная модель - калькулятор. Суть ее: получить данные от пользователя, определенным образом обработать и вернуть некоторый ответ. Инфа и данные могут быть при этом совершенно различными: числовыми - определение стоимости заказа, ипотечный калькулятор; текстовыми - генерация файла robots.txt по веденным в поле данным; графическими - генератор иконки и т.д. Примеров можно привести много. Всех их объединяет линейная архитектура. Без пользователей, баз данных и т.д. - получили, обработали, отдали.
Мелкие кирпичи-уточнения на фундаменте строят ПРОЕКТ. Если один из кирпичей вам окажется не под силу, или займет слишком много времени… ну в общем, никому этого не хочется. И никому не выгодно. Поэтому, несколько советов:
1. Определитесь с сущностью. Выполняли ли вы что-то подобное ранее? Если определились с мейнстримом, то далее постарайтесь разбить задание на этапы, операции и структуры. Это, в первую очередь, важно для того, чтобы навести в голове порядок. Во-вторых, чем точнее вы определите составляющие части, тем точнее определите общее время разработки… и стоимость, естественно.
2. Если вы работаете без ТЗ, то это уже не программирование - это свободное творчество, и оно обычно только отнимает у вас силы, а у заказчика время. Поэтому пишите ТЗ заранее! Согласовывайте его и потом только принимайтесь за реализацию. Конечно, некоторые поправки и коррективы в ходе разработки нужны, но не увлекайтесь ими.
3. Если у вас в руках есть готовое, хорошо продуманное ТЗ, вы.. нет, не бросаетесь с головой в написание сотен строк программного кода. Сядьте и спланируйте все хорошо. Это сэкономит вам время и силы. Переделывать уже сделанное очень неприятно. Лучше обходиться без этого 
4. Если в описании проекта заказчик пишет “ну и некоторые другие мелочи” - смело поднимайте цену на 30-50%. Поверьте, эти мелочи потом выходят боком: то ли оказывается, что они противоречат предыдущей работе, то ли МЕЛОЧЬ оказывается отдельным блоком работы (и не самым простым). Или еще хуже - окажеться, что заказчик сам не знает, чего он хочет. Тогда либо разработка накроется, либо функция “допланирования” ляжет на ваши плечи. Оно вам надо?
5. Если некоторые “мелочи” вызывают подозрение того, что это вовсе НЕ МЕЛОЧИ :), скажите об этом заказчику сразу. Ведь заказчик не обязательно должен быть программистом, он не обязан понимать какая работа стоит за той или иной спецификой проекта, может недооценивать или наоборот переоценивать ее. Но вы ведь можете ему на это указать!
6. Детали и мелочи забирают много времени! Это чисто практическое наблюдение: всегда хочеться сказать “да это просто, я быстро сделаю”. Подходите максимально ответственно к каждой мелочи.
И последний и самый действенный совет - практикуйтесь и учитесь новому. Успехов.
Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!
Также читайте по теме:
- 18 сентября
Вы читали литературу по проектному менеджменту? Я где-то видел этот велосипед…
Бруно, я учусь на банкира
я читал книги и по проектному менеджменту, и по проектному инвестированию, и по проектому финансированию, и по проектному анализу…
В заметку я вложил в первую очередь свой личный опыт, а не сотни страниц теории, которые без практики бесполезны.
насчет мелочей хорошо сказано
“Поэтому пишите ТЗ заранее! Согласовывайте его и потом только принимайтесь за реализацию”
разве не заказчик должен предоставить ТЗ ?
Если бы все в нашей жизни было так просто…
Конечно, есть заказчики, которые предоставляют подробное продуманное ТЗ, но чаще всего за помощью к программисту идут люди с ИДЕЕЙ. К примеру, вам пишет человек: “нужно сделать рейтинг блогов, так чтобы читалась РСС и алекса ранк… И чтобы работало хорошо”. Вот вам и все ТЗ. Приходится самому все планирвать, выяснять…
Мне кажется это естествеено: для написания грамотного ТЗ нужен опыт и понимание процесса разработки. А это глупо требовать от заказчиков. Вы ведь когда приходите вбанк депозит положить, с вас же не просят подробный вами разработанный депозитный договор, просто уточнят у вас цели и детали, и напишут сами
вообще логично конечно)
“А это глупо требовать от заказчиков”
А вообще глупо, что-либо требовать от заказчиков…
По большому счету ДА, но я всегда требую разъяснения общего “видения” проекта. Если такого нет, то предпочитаю не браться