Пользователь
0,0
рейтинг
29 июля 2012 в 11:08

Управление → Фриланс как средство заработка. Ч.1. Старт проекта

В предыдущих своих постах я постарался рассказать о том, как взаимодействуют фрилансер и заказчик. Большинство мыслей, представленных в этих статьях, были самим собой разумеющимся, на что мне указывали, и не раз. Сегодня я бы хотел начать разговор о том, как мы, благополучно пройдя все перипетии первоначального обсуждения, начинаем проект. Я опять буду банален до безобразия, вновь и вновь буду перетирать то, что каждому понятно. Но, как показывает практика, все мы с упорством мазохистов наступаем на одни и те же грабли.

Начинаем работы

Итак, все прекрасно. Вы благополучно убедили заказчика, что вы и есть тот самый чудесный/наикрутейший/наидобрейший исполнитель, который выполнит главную хотелку «чтоб херак одну кнопку, оно вжиииик, и все готово». Поздравляю вас с этим, начинаем переговоры о конкретике.

Немного отвлекусь.
95% тех, кто читает этот пост, имеют на данный момент опыт/ведут такой проект/ведут проект и не знают что он такой. Какой? Который, хоть порви все на себе, не закончится в срок, выставленный вами, и никогда не будет стоить столько, сколько было озвучено. Сдав такой проект, поссорившись с заказчиком (ну а фигли, я такой прекрасный, перевыполнил план работ, вышел за рамки ТЗ, а он тут пальцы гнет), мы откинемся на кресле, утрем пот со лба, разотрем краснющие глаза, критически осмотрим мозоли от клавиш, и благополучно пообещаем себе, что такого не повторится. И вляпаемся в такое же г на следующем проекте. Я долго думал, почему так происходит, и хотел бы поделиться с Вами своими мыслями и приемами, которые позволяют избежать подобных проблем.

Во время начала работ все мы заняты реверансами с заказчиком, вычитываем письма, хвастаем портфолио. В то же время, когда возникает реальная возможность блеснуть своими навыками, мы плюем на нее, топчем в грязь, и закладываем под себя мину замедленного действия. О чем я? О стоимости и сроках.

Я не раз сталкивался, ну и что уж там, сам грешен, с тем, что в маленьких группах разработчиков/у индивидуальных разработчиков процент верной оценки стоимости и сроков обратно пропорционален размеру проекта. грань индивидуальна, но всегда просматриваема. Как правило, грань равна двойной сумме самого крупного проекта. Т.е. если исполнитель до этого работал с проектом на 150 т.р., то оценка стоимости и сроков для проекта, стоимость которого 300 т.р., будет неверной. Не «скорее всего столько», и даже не «может быть столько», а именно неверной. Сделайте запись авторучкой прям на коре головного мозга

Если вы оцениваете проект с двукратным превышением стоимости самого дорогого вашего проекта, то вы нагло, беззастенчиво врете

Врете себе, заказчику, да и законам этого мира, если уж перечислять все.

Ну хватит уж распаляться, думаю все все поняли, переходим к тому, что собственно с этим делать.

Лекарство

Лекарства, как известно, бывают двух видов. Таблеточка от простуды и комплекс препаратов от тяжелого заболевания. К какому виду отнести превышение сроков и бюджета? А вы еще сомневаетесь?

Начнем с подготовки пациента.
Проблема, если разобраться в сути, в наших мозгах. Вот только не надо сейчас начинать цитировать Задорнова и рассказывать что нация наша есть суть набор расп раздолбаев. Нет, конечно у нас чувство ответственности за результат гораздо меньше, чем у тех же самых японцев или немцев. Но 95% — показатель выхода из рамок бюджета не только для отрасли программирования. И не только в нашей стране. Статистику взял из кучи книг по управлению проектов, которые пришлось перелопатить.

Но мы отвлеклись. Проблема в мозгах. Признайте это, и станет легче и проще искать выход. Ведь всегда есть соблазн сослаться на неадекватного заказчика, меняющего ТЗ, на идиотизм тех, кто реализовывал API для библиотек, которые были использованы в проекте, да на фазу луны, в конце концов. Но открою тайну — заказчики в основной массе своей именно таковы. Есть конечно отклонения как в лучшую так и в худшую сторону, но основа одинакова. А библиотеки писались именно так, потому что на то есть вполне адекватная причина, о которой вы можете и не знать. Ну а фаза луны влияет на окияны, к коим себя вы вряд ли относите.

Начнем с того, как выставляются сроки и бюджет. Если проект небольшой, тысяч на 20, и сроком работы дней на 5, то тогда у нас проблем не возникает, верно? А почему? Потому что с одной стороны все наши промахи отображаются в процентном отношении от параметров проекта. И если для приведенного отклонение в 30-40% это 1,5-2 дня и 6-8 т.р., которыми можно пожертвовать, то в большом порядки уже другие. Реальность такова, что указанные мною отклонения — это очень хороший показатель. Почему? Едем дальше. Вторая причина того, что сроки называются более менее достоверно — проект чисто физически проще оценить и обозреть. На больших проектах видение трудоемкости работ очень расплывчато.

Отдельно хотелось бы выделить проекты, которые похожи на то, что уже приходилось выполнять. Сколько нам открытий чудных… Все любят истории, когда автор попадает в дурацкую ситуацию, потому приведу пример из личного опыта. Как то пришлось столкнуться с проектом, который был как две капли похож на то. что уже приходилось делать. Надо ли говорить, что проект в два раза превысил сроки, не говоря уж о головняках с заказчиком и упущенной выгоде? Конечно, не обошлось без вмешательства со стороны заказчика, представитель которого в начале обещал уточнять все моменты, а после подписания договора начал лажать. Но мы уже договорились, что в первую очередь в фейлах виноваты мы сами.

Замечаете, как описание проблем по сути дает ответы на них? Рассмотрим подробней.

Во первых, катастрофически мало времени уделяется ТЗ. Да, бывают ситуации, когда можно работать без него. Например у меня есть заказчик, с которым мы работаем вообще без ТЗ, при этом не вызывает никаких вопросов изменение сроков и стоимости после изменения первоначальных договоренностей. Но на сотню проектов у меня такой положительный пример только один.

Чем больше ТЗ, тем меньше уделяется времени анализу его, родимого. Отсюда — проблемы с стоимостью и сроками. Большое ТЗ как правило означает много работы. И иногда просто стремно назвать заказчику не 100 т.р. за проект и 1,5 мес (которые мы конечно взяли тупо из головы), а триста и 4 мес. Не надо бояться!!! Если заказчик не готов платить за ваш труд, а это именно труд, а не ковыряние в носу, то нечего и начинать.

Проблема осложняется тем, что заказчик, как правило, не заинтересован в точной оценке стоимости. Да-да, вы не ослышались. Заказчик заинтересован в быстрой оценке. Это вытекает из того, что обращаясь на фриланс, он получает десятки предложений. А так как зачастую проект нужно было сделать «еще вчера», то главную скрипку играет время получения оценок стоимости и сроков, на основе которых делается выбор. Поэтому анализ ТЗ — исключительно ваша забота.

Как с этим бороться? Достаточно просто — разбейте проект на блоки. Схема называется PERT диаграммой. Как ее выполнять — примеров в интернете полно. Разбивка не займет много времени, а оценивать по трудоемкости отдельные части гораздо проще. Оценку выполняйте так, как будто это — отдельная разработка. При этом, для определения точных сроков неплохо умножить полученную сумму на 1.2, чтобы обеспечить себе время на сведение проекта. На сколько умножать итоговые цифры, чтобы обеспечить себе запас в виде буфера — личный вопрос каждого :)

Тут, скорее всего, могла бы помочь какая либо комплексная программа по выполнению оценочных работ, но ее к сожалению я не нашел. Далее я расскажу о других этапах и приемах, и вы поймете, почему я так говорю. Даже в книгах по управлению проектами приводится 3-4 программных продукта, при этом на всех этапах выполняется анализ то в одной, то в другой программе. За время работы я использовал несколько продуктов, и могу с уверенностью сказать, что если в одной программе что то выполняется легко и просто, то в другой это вообще не предусмотрено, либо сделано через одно место.
Была мысля написать программу для управления проектами, но в одиночку выполнять работы достаточно сложно, особенно в условиях большой занятости, а сподвигнуть на это своих ребят я не смог :) Так что как только — так сразу, расскажу о итогах по завершению проекта.

Что то я расписался… Думаю, на сегодня хватит, в следующей части рассмотрим проблемы начала непосредственно работ над проектом.

часть два.
@dtcDev
карма
68,5
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (19)

  • +3
    Во многих местах в точку! Написано красиво… но мало: только начал зачитываться, как все, конец.
    Жду продолжения.
    • 0
      Будет. Обязательно :) Просто надо было срочно уехать
    • +4
  • 0
    >При этом, для определения точных сроков неплохо умножить полученную сумму на 1.2
    Вообще-то гуру советуют на Пи умножать, один фиг мимо получиться :)

    >Схема называется PERT диаграммой
    Вообще-то PERT это уже планирование, а то что вы имеете в виду называется WBS. И смысл в том что бы непонятные по сроками и прочему блоки разбивать на более мелкие, до тех пор пока все блоки будут иметь четкие и понятные сроки, лучше всего не оценки, а исторически известные из прошлого опыта. Правда начинающему все равно не поможет, потому что
    — разбиение будет не совсем верным и в реальности будут несколько другие блоки
    — какие-то работы будут пропущены, типичные случаи — документация, интеграция, мердж, тестирование и багфиксинг
    — блоки, вроде бы элементарные, без опыта построения таковых, занимают больше или меньше времени в реальности
    Я уж молчу про типичные проблемы работы по WBS, как-то завышение сроков в результате излишне подробного разбиения, задержки в результате технического долга работы по мелким блокам, неконтролируемое использования буфера в связи с тем что «мы идем по плану» и так далее

    Проблемы с программами в том что они пишутся под какой-то известный цикл и правила оценки и отслеживания. Если мало понимания того что имели в виду разработчики данного ПО, то любой будет либо неудобным либо сложным. В любом случае надо пробовать и применять. По опыту могу сказать что если ПМ к работе подходит ответственно то все заканчивается шлифовкой напильником какого-нить web based ПО, потому что проще. В конце концов показать гант или посчитать пути в сетевой диаграмме много ума не надо.
    • 0
      спасибо за уточнения.

      Было очень интересно прочесть Ваше мнение. Скажите, Вы можете посоветовать какой либо конкретный софт, которым пользуетесь?
      • 0
        Ну когда-то показал себя неплохо микрософтовский проджект — простой и понятный, но он хорош только на этапе планирования и работу с ресурсами там надо напильником подкручивать. В добавок там многое разрешено менять, так что история проекта теряется. Прочие же вещи у нас на том этапе были интегрированы с пачкой продуктов от Rational — Clear Case, Clear Quest. В целом же для сопровождения проекта MsProject невнятен.

        Повзрослев мы перешли на самописные продукты тесно увязанные с нашими циклами работы.

        Уйдя во фриланс я поначалу пробовал кучку разных, но подходящий для меня не нашел. WBS предпочитаю делать в блокноте ручкой — получается намного быстрее и качественнее :)
        • 0
          вот, согласен.

          почему то вся документация представляет собой по каждому проекту папку с файлами, в которых живут бумажки, исписанные ручкой. А с софтом как то не вяжется…

          Проджект во многом хорош, но некоторые вещи, в частности да, ресурсы — просто убиться головой об стену
  • 0
    Да, вроде как всё очевидно и ничего особо нового — но по полочкам разложено очень хорошо. отлично написано.

    По поправочным коэффициентам.
    Я после оценки в обязательном порядке (даже если проект небольшой и внешне очень простой) накидываю 10-15%. Это железный минимум. И надо сказать, что практически не бывает случая, чтобы этот запас не был потрачен.
    Если что-то пообъемнее/посложнее, то да, 30-40% где-то.

    И отдельной строкой нельзя забывать время, потраченное на разговоры/обсуждения/согласования — иногда оно может быть очень значительным.
    • 0
      Спасибо.

      Готова вторая часть.

      что касается увеличения сроков, то об этом я планирую детально поговорить в третьей части, там же и коснусь указанных Вами вопросов
  • +1
    Давно для себя применяю такую схему:
    1. Выполняя очередной проект, веду хронометраж времени (каким образом конкретизировать не буду, программ много).
    2. В итоге за пару лет сформировался большой багаж статистики. Составил таблицу (и постоянно ее дополняю) где отображены разные этапы разных проектов и время, затраченное на них. Хоть все проекты и разные, но этапы в 80% случаев повторяются.
    3. При оценке нового проекта, разбиваю его на этапы, смотрю свою таблицу и оцениваю временные затраты. Как писал выше, этапы очень часто бывают аналогичными, поэтому возможно довольно точно оценить временные затраты.
    Система очень проста, работает и ОЧЕНЬ помогает.
    Одна сложность — приучить себя вести хронометраж. Наверное это не так просто взять да и начать его вести. Я в свое время увлекся методиками тайм-менеджемента, поэтому и ведение постоянного хронометража заняло в моей работе важную роль.
    Рекомендую почитать Глеба Архангельского.
    • 0
      Спасибо за наводку, попробую почитать.

      скажите, как Вы укладываете при такой методике разброс функций. Банально — список пользователей. Одно дело — имя/логин/пароль/мыло, другое — 20 параметров, причем раскиданных по разным таблицам. Как быть в таком случае?
      • +1
        Не совсем понял ваш вопрос!…
        • 0
          Ну я к тому, что у Вас блоки учитывают большую вариативность формально одинаковых задач, или нет?
          • 0
            Вариативность есть, но она не настолько большая. Тем более я в своей таблице фиксирую одинаковые задачи для разных проектов. Разные проекты имеют разную сложность и разные нюансы — согласен. Соответственно, и при планировании очередного проекта, при оценке времени конкретного этапа, я смотрю в таблице среднее время затраты на этот этап и учитываю особенности нового проекта. Тем более что как правило в таблице уже есть схожие проекты и соответственно время этапа можно брать за основу именно из этих схожих проектов. Не забывая и про среднее время, затрачиваемое на этот этап, по итогам всей таблицы. Схема в некоторых моментах расплывчатая, но мне очень помогает. Я очень редко ошибаюсь в расчете времени. И соответственно все этапы могу рассовать по календарю на ближайшие неделю-две. И тогда все под контролем.
  • +2
    В целом статья написана живо, с юмором, Задорновым и вые зачеркиваниями, но я поставил вам минус. И вот почему:
    1. Где картинки? Хоть одна. Хотя бы рядом с PERT диаграммой.
    2. В чем состоит цель вашей статьи? 95% ваших читателей фейлят проекты потому что срываются сроки, но после прочтения Вашей статьи этот процент не уменьшится ни на йоту. Потому что вы не предлагаете решение. Разбить ТЗ на блоки или умножить время на 1.2, извините, но это же и так очевидно, имхо.
    Статистику взял из кучи книг по управлению проектов, которые пришлось перелопатить.

    3. Вау! Класс! Книжки! Куча! Управление проектами! Ссылки? Авторы? Названия? Ну вы понимаете, о чем я...

    Не сочтите, меня за толстого тролля, но в этой статье нет ничего. Вместо абстрактных подсчетов стоимости проекта и процентов взятых с потолка приведите один пример. Понятное дело, что реальные ТЗ выкладывать сюда не стоит, но давайте вместе придумаем какой нибудь example.com, сроки которого сколько-то месяцев, а функциональность размазана на столько-то блоков? Расскажите, как правильно вытащить из заказчика всю нужную информацию за минимальное количество итераций. Поведайте о том, как добиться лучшего понимания у заказчика в вопросах взаимодействия различных частей проекта, чтобы когда на середине в его буйную голову постучится дрозд он осознавал какой объем работ придется переделывать. Как вовлечь заказчика в процесс разработки с целью получения быстрого отклика на неочевидные моменты реализации? Спасибо.
    • +1
      На то часть и первая. Извините, но за время своей работы я столько раз сталкивался с тем, что даже при очевидной проблеме со стороны исполнителя, не говоря уж о том, что есть не столь очевидные, заставить человека сказать «да, это мой косяк, давай подумаем что делать с этим дальше» настолько трудно, что иногда просто за голову берешься. Этой вводной частью я пытался достучаться до тех, кто в танке. До тех, кто готов винить что угодно и кого угодно, лишь бы не признавать того, что главная причина всех бед — он сам.

      Написать статью на тему «ох какие заказчики скоты»? Неа, не скоты.

      Привести пример? Будет пример, обязательно будет. Только дайте войти в процесс. Когда то меня до скрежета зубовного за… ло, что почти все проекты не заканчиваются в срок и выходят за рамки бюджета. И я стал думать, анализировать, читать. Хотите чтобы я в рамках одной статьи рассказал как все будет круто и как делать? Не могу. Не получится. Ибо мысли, которые я озвучивал с коллегами еще год назад, подозрительно перекликаются с тем, к чему я пришел. А толку? Пока не прожевал, пока все не озвучил — нифига не работало.

      Потому и статьи будут размазаны на несколько, уж извините.

      Ну а что касается картинок, то как то не привык, что ли :) Тут уж извините :)
      • 0
        Спасибо. В любом случае статья получилась интересной и я с удовольствием осознал что большинство из ваших мыслей мне близки, и до идей которые вы излагаете так или иначе я тоже дошел в процессе своей работы.
        Вы совершенно правы, они не скоты. Несомненно иногда проскакивают совсем уж лиственные породы деревьев, но в общем массе они знают чего хотят и требуют бережно относиться к их идеям и мыслям. О том, как отказываться от работы с заказчиком, потому что он бревно, и никакими разумными издержками этого не покрыть, я думаю вы тоже упомянете где нибудь (раз уж диалог с читателями планирует быть долгим :), но это тема для отдельного обсуждения.
        Мне же хотелось дать вам обратную связь, чтобы следующие части были более структурированы, логичны и наполнены картинками и примерами. Я не зря делаю акцент на картинках, к которым вы как-то не привыкли: ) Читать полотна текста, пусть и написанного самым лучших рассказчиком, очень утомительно. Картинки разряжают текст, дают возможность глазам отдохнуть чуть чуть перед новым погружением в пучины ваших размышлений. Не говоря уже о том, что информацию можно представлять в различных формах, и иногда выбор удачной формы влечет за собой лучшее понимание содержания.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    На интуите есть хорошая книга по теме "Компонентный подход в программировании".
    Правда, она с уклоном на Java и NET, но тем не менее есть что почерпнуть и разработчикам использующим другие ЯП.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.