В предыдущих своих постах я постарался рассказать о том, как взаимодействуют фрилансер и заказчик. Большинство мыслей, представленных в этих статьях, были самим собой разумеющимся, на что мне указывали, и не раз. Сегодня я бы хотел начать разговор о том, как мы, благополучно пройдя все перепетии первоначального обсуждения, начинаем проект. Я опять буду банален до безобразия, вновь и вновь буду перетирать то, что каждому понятно. Но, как показывает практика, все мы с упорством мазохистов наступаем на одни и те же грабли.
Начинаем работы
Итак, все прекрасно. Вы благополучно убедили заказчика, что вы и есть тот самый чудесный/наикрутейший/наидобрейший исполнитель, который выполнит главную хотелку «чтоб херак одну кнопку, оно вжиииик, и все готово». Поздравляю вас с этим, начинаем переговоры о конкретике.
Немного отвлекусь.
95% тех, кто читает этот пост, имеют на данный момент опыт/ведут такой проект/ведут проект и не знают что он такой. Какой? Который, хоть порви все на себе, не закончится в срок, выставленный вами, и никогда не будет стоить столько, сколько было озвучено. Сдав такой проект, поссорившись с заказчиком (ну а фигли, я такой прекрасный, перевыполнил план работ, вышел за рамки ТЗ, а он тут пальцы гнет), мы откинемся на кресле, утрем пот со лба, растрем краснющие глаза, критически осмотрим мазоли от клавиш, и благополучно пообещаем себе, что такого не повторится. И вляпаемся в такое же г на следующем проекте. Я долго думал, почему так происходит, и хотел бы поделиться с Вами своими мыслями и приемами, которые позволяют избежать подобных проблем.
Во время начала работ все мы заняты реверансами с заказчиком, вычитываем письма, хвастаем портфолио. В то же время, когда возникает реальная возможность блеснуть своими навыками, мы плюем на нее, топчем в грязь, и закладываем под себя мину замедленного действия. О чем я? О стоимости и сроках.
Я не раз сталкивался, ну и что уж там, сам грешен, с тем, что в маленьких группах разработчиков/у индивидуальных разработчиков процент верной оценки стоимости и сроков обратно пропорционален размеру проекта. грань индивидуальна, но всегда просматриваема. Как правило, грань равна двойной сумме самого крупного проекта. Т.е. если исполнитель до этого работал с проектом на 150 т.р., то оценка стоимости и сроков для проекта, стоимость которого 300 т.р., будет неверной. Не «скорее всего столько», и даже не «может быть столько», а именно неверной. Сделайте запись авторучкой прям на коре головного
Если вы оцениваете проект с двухкратным превышением стоимости самого дорогого вашего проекта, то вы нагло, беззастенчиво врете
Врете себе, заказчику, да и законам этого мира, если уж перечислять все.
Ну хватит уж распаляться, думаю все все поняли, переходим к тому, что собственно с этим делать.
Лекарство
Лекарства, как известно, бывают двух видов. Таблеточка от простуды и комплекс препаратов от тяжелого заболевания. К какому виду отнести превышение сроков и бюджета? А вы еще сомневаетесь?
Начнем с подготовки пациента.
Проблема, если разобраться в сути, в наших мозгах. Вот только не надо сейчас начинать цитировать Задорнова и рассказывать что нация наша есть суть набор расп раздолбаев. Нет, конечно у нас чувство ответственности за результат гораздо меньше, чем у тех же самых японцев или немцев. Но 95% — показатель выхода из рамок бюджета не только для отрасли программирования. И не только в нашей стране. Статистику взял из кучи книг по управлению проектов, которые пришлось перелопатить.
Но мы отвлеклись. Проблема в мозгах. Признайте это, и станет легче и проще искать выход. Ведь всегда есть соблазн сослаться на неадекватного заказчика, меняющего ТЗ, на идиотизм тех, кто реализовывал API для библиотек, которые были использованы в проекте, да на фазу луны, в конце концов. Но открою тайну — заказчики в основной массе своей именно таковы. Есть конечно отклонения как в лучшую так и в худшую сторону, но основа одинакова. А библиотеки писались именно так, потому что на то есть вполне адекватная причина, о которой вы можете и не знать. Ну а фаза луны влияет на окияны, к коим себя вы врят ли относите.
Начнем с того, как выставляются сроки и бюджет. Если проект небольшой, тысяч на 20, и сроком работы дней на 5, то тогда у нас проблем не возникает, верно? А почему? Потому что с одной стороны все наши промахи отображаются в процентном отношении от параметров проекта. И если для приведенного отклонение в 30-40% это 1,5-2 дня и 6-8 т.р., которыми можно пожертвовать, то в большом порядки уже другие. Реальность такова, что указанные мною отклонения — это очень хороший показатель. Почему? Едем дальше. Вторая причина того, что сроки называются более менее достоверно — проект чисто физически, по человечи проще оценить и обозреть. На больших проектах видение трудоемкости работ очень расплывчато.
Отдельно хотелось бы выделить проекты, которые похожи на то, что уже приходилось выполнять. Сколько нам открытий чудных… Все любят истории, когда автор попадает в дурацкую ситуацию, потому приведу пример из личного опыта. Как то пришлось столкнуться с проектом, который был как две капли похож на то. что уже приходилось делать. Надо ли говорить, что проект в два раза превысил сроки, не говоря уж о головняках с заказчиком и упущенной выгоде? Конечно, не обошлось без вмешательства со стороны заказчика, представитель которого в начале обещал уточнять все моменты, а после подписания договора начал лажать. Но мы уже договорились, что в первую очередь в фейлах виноваты мы сами.
Замечаете, как описание проблем по сути дает ответы на них? Рассмотрим подробней.
Во первых, катастрофически мало времени уделяется ТЗ. Да, бывают ситуации, когда можно работать без него. Например у меня есть заказчик, с которым мы работаем вообще без ТЗ, при этом не вызывает никаких вопросов изменение сроков и стоимости после изменения первоначальных договоренностей. Но на сотню проектов у меня такой положительный пример только один.
Чем больше ТЗ, тем меньше уделяется времени анализу его, родимого. Отсюда — проблемы с стоимостью и сроками. Большое ТЗ как правило означает много работы. И иногда просто стремно назвать заказчику не 100 т.р. за проект и 1,5 мес (которые мы конечно взяли тупо из головы), а триста и 4 мес. Не надо бояться!!! Если заказчик не готов платить за ваш труд, а это именно труд, а не ковыряние в носу, то нечего и начинать.
Проблема осложняется тем, что заказчик, как правило, не заинтересован в точной оценке стоимости. Да-да, вы не ослышались. Заказчик заинтересован в быстрой оценке. Это вытекает из того, что обращаясь на фриланс, он получает десятки предложений. А так как зачастую проект нужно было сделать «еще вчера», то главную скрипку играет время получения оценок стоимости и сроков, на основе которых делается выбор. Поэтому анализ ТЗ — исключительно ваша забота.
Как с этим бороться? Достаточно просто — разбейте проект на блоки. Схема называется PERT диаграммой. Как ее выполнять — примеров в интернете полно. Разбивка не займет много времени, а оценивать по трудоемкости отдельные части гораздо проще. Оценку выполняйте так, как будто это — отдельная разработка. При этом, для определения точных сроков неплохо умножить полученную сумму на 1.2, чтобы обеспечить себе время на сведение проекта. На сколько умножать итоговые цифры, чтобы обеспечить себе запас в виде буфера — личный вопрос каждого :)
Тут, скорее всего, могла бы помочь какая либо комплексная программа по выполнению оценочных работ, но ее к сожалению я не нашел. Далее я расскажу о других этапах и приемах, и вы поймете, почему я так говорю. Даже в книгах по управлению проектами приводится 3-4 программных продукта, при этом на всех этапах выполняется анализ то в одной, то в другой программе. За время работы я использовал несколько продуктов, и могу с уверенностью сказать, что если в одной программе что то выполняется легко и просто, то в другой это вообще не предусмотрено, либо сделано через одно место.
Была мысля написать программу для управления проектами, но в одиночку выполнять работы достаточно сложно, особенно в условиях большой занятости, а сподвигнуть на это своих ребят я не смог :) Так что как только — так сразу, расскажу о итогах по завершению проекта.
Что то я расписался… Думаю, на сегодня хватит, в следующей части рассмотрим проблемы начала непосредственно работ над проектом.
Автор: dtcDev
