Comments 19
Во многих местах в точку! Написано красиво… но мало: только начал зачитываться, как все, конец.
Жду продолжения.
Жду продолжения.
>При этом, для определения точных сроков неплохо умножить полученную сумму на 1.2
Вообще-то гуру советуют на Пи умножать, один фиг мимо получиться :)
>Схема называется PERT диаграммой
Вообще-то PERT это уже планирование, а то что вы имеете в виду называется WBS. И смысл в том что бы непонятные по сроками и прочему блоки разбивать на более мелкие, до тех пор пока все блоки будут иметь четкие и понятные сроки, лучше всего не оценки, а исторически известные из прошлого опыта. Правда начинающему все равно не поможет, потому что
— разбиение будет не совсем верным и в реальности будут несколько другие блоки
— какие-то работы будут пропущены, типичные случаи — документация, интеграция, мердж, тестирование и багфиксинг
— блоки, вроде бы элементарные, без опыта построения таковых, занимают больше или меньше времени в реальности
Я уж молчу про типичные проблемы работы по WBS, как-то завышение сроков в результате излишне подробного разбиения, задержки в результате технического долга работы по мелким блокам, неконтролируемое использования буфера в связи с тем что «мы идем по плану» и так далее
Проблемы с программами в том что они пишутся под какой-то известный цикл и правила оценки и отслеживания. Если мало понимания того что имели в виду разработчики данного ПО, то любой будет либо неудобным либо сложным. В любом случае надо пробовать и применять. По опыту могу сказать что если ПМ к работе подходит ответственно то все заканчивается шлифовкой напильником какого-нить web based ПО, потому что проще. В конце концов показать гант или посчитать пути в сетевой диаграмме много ума не надо.
Вообще-то гуру советуют на Пи умножать, один фиг мимо получиться :)
>Схема называется PERT диаграммой
Вообще-то PERT это уже планирование, а то что вы имеете в виду называется WBS. И смысл в том что бы непонятные по сроками и прочему блоки разбивать на более мелкие, до тех пор пока все блоки будут иметь четкие и понятные сроки, лучше всего не оценки, а исторически известные из прошлого опыта. Правда начинающему все равно не поможет, потому что
— разбиение будет не совсем верным и в реальности будут несколько другие блоки
— какие-то работы будут пропущены, типичные случаи — документация, интеграция, мердж, тестирование и багфиксинг
— блоки, вроде бы элементарные, без опыта построения таковых, занимают больше или меньше времени в реальности
Я уж молчу про типичные проблемы работы по WBS, как-то завышение сроков в результате излишне подробного разбиения, задержки в результате технического долга работы по мелким блокам, неконтролируемое использования буфера в связи с тем что «мы идем по плану» и так далее
Проблемы с программами в том что они пишутся под какой-то известный цикл и правила оценки и отслеживания. Если мало понимания того что имели в виду разработчики данного ПО, то любой будет либо неудобным либо сложным. В любом случае надо пробовать и применять. По опыту могу сказать что если ПМ к работе подходит ответственно то все заканчивается шлифовкой напильником какого-нить web based ПО, потому что проще. В конце концов показать гант или посчитать пути в сетевой диаграмме много ума не надо.
спасибо за уточнения.
Было очень интересно прочесть Ваше мнение. Скажите, Вы можете посоветовать какой либо конкретный софт, которым пользуетесь?
Было очень интересно прочесть Ваше мнение. Скажите, Вы можете посоветовать какой либо конкретный софт, которым пользуетесь?
Ну когда-то показал себя неплохо микрософтовский проджект — простой и понятный, но он хорош только на этапе планирования и работу с ресурсами там надо напильником подкручивать. В добавок там многое разрешено менять, так что история проекта теряется. Прочие же вещи у нас на том этапе были интегрированы с пачкой продуктов от Rational — Clear Case, Clear Quest. В целом же для сопровождения проекта MsProject невнятен.
Повзрослев мы перешли на самописные продукты тесно увязанные с нашими циклами работы.
Уйдя во фриланс я поначалу пробовал кучку разных, но подходящий для меня не нашел. WBS предпочитаю делать в блокноте ручкой — получается намного быстрее и качественнее :)
Повзрослев мы перешли на самописные продукты тесно увязанные с нашими циклами работы.
Уйдя во фриланс я поначалу пробовал кучку разных, но подходящий для меня не нашел. WBS предпочитаю делать в блокноте ручкой — получается намного быстрее и качественнее :)
Да, вроде как всё очевидно и ничего особо нового — но по полочкам разложено очень хорошо. отлично написано.
По поправочным коэффициентам.
Я после оценки в обязательном порядке (даже если проект небольшой и внешне очень простой) накидываю 10-15%. Это железный минимум. И надо сказать, что практически не бывает случая, чтобы этот запас не был потрачен.
Если что-то пообъемнее/посложнее, то да, 30-40% где-то.
И отдельной строкой нельзя забывать время, потраченное на разговоры/обсуждения/согласования — иногда оно может быть очень значительным.
По поправочным коэффициентам.
Я после оценки в обязательном порядке (даже если проект небольшой и внешне очень простой) накидываю 10-15%. Это железный минимум. И надо сказать, что практически не бывает случая, чтобы этот запас не был потрачен.
Если что-то пообъемнее/посложнее, то да, 30-40% где-то.
И отдельной строкой нельзя забывать время, потраченное на разговоры/обсуждения/согласования — иногда оно может быть очень значительным.
Давно для себя применяю такую схему:
1. Выполняя очередной проект, веду хронометраж времени (каким образом конкретизировать не буду, программ много).
2. В итоге за пару лет сформировался большой багаж статистики. Составил таблицу (и постоянно ее дополняю) где отображены разные этапы разных проектов и время, затраченное на них. Хоть все проекты и разные, но этапы в 80% случаев повторяются.
3. При оценке нового проекта, разбиваю его на этапы, смотрю свою таблицу и оцениваю временные затраты. Как писал выше, этапы очень часто бывают аналогичными, поэтому возможно довольно точно оценить временные затраты.
Система очень проста, работает и ОЧЕНЬ помогает.
Одна сложность — приучить себя вести хронометраж. Наверное это не так просто взять да и начать его вести. Я в свое время увлекся методиками тайм-менеджемента, поэтому и ведение постоянного хронометража заняло в моей работе важную роль.
Рекомендую почитать Глеба Архангельского.
1. Выполняя очередной проект, веду хронометраж времени (каким образом конкретизировать не буду, программ много).
2. В итоге за пару лет сформировался большой багаж статистики. Составил таблицу (и постоянно ее дополняю) где отображены разные этапы разных проектов и время, затраченное на них. Хоть все проекты и разные, но этапы в 80% случаев повторяются.
3. При оценке нового проекта, разбиваю его на этапы, смотрю свою таблицу и оцениваю временные затраты. Как писал выше, этапы очень часто бывают аналогичными, поэтому возможно довольно точно оценить временные затраты.
Система очень проста, работает и ОЧЕНЬ помогает.
Одна сложность — приучить себя вести хронометраж. Наверное это не так просто взять да и начать его вести. Я в свое время увлекся методиками тайм-менеджемента, поэтому и ведение постоянного хронометража заняло в моей работе важную роль.
Рекомендую почитать Глеба Архангельского.
Спасибо за наводку, попробую почитать.
скажите, как Вы укладываете при такой методике разброс функций. Банально — список пользователей. Одно дело — имя/логин/пароль/мыло, другое — 20 параметров, причем раскиданных по разным таблицам. Как быть в таком случае?
скажите, как Вы укладываете при такой методике разброс функций. Банально — список пользователей. Одно дело — имя/логин/пароль/мыло, другое — 20 параметров, причем раскиданных по разным таблицам. Как быть в таком случае?
Не совсем понял ваш вопрос!…
Ну я к тому, что у Вас блоки учитывают большую вариативность формально одинаковых задач, или нет?
Вариативность есть, но она не настолько большая. Тем более я в своей таблице фиксирую одинаковые задачи для разных проектов. Разные проекты имеют разную сложность и разные нюансы — согласен. Соответственно, и при планировании очередного проекта, при оценке времени конкретного этапа, я смотрю в таблице среднее время затраты на этот этап и учитываю особенности нового проекта. Тем более что как правило в таблице уже есть схожие проекты и соответственно время этапа можно брать за основу именно из этих схожих проектов. Не забывая и про среднее время, затрачиваемое на этот этап, по итогам всей таблицы. Схема в некоторых моментах расплывчатая, но мне очень помогает. Я очень редко ошибаюсь в расчете времени. И соответственно все этапы могу рассовать по календарю на ближайшие неделю-две. И тогда все под контролем.
В целом статья написана живо, с юмором, Задорновым и вые зачеркиваниями, но я поставил вам минус. И вот почему:
1. Где картинки? Хоть одна. Хотя бы рядом с PERT диаграммой.
2. В чем состоит цель вашей статьи? 95% ваших читателей фейлят проекты потому что срываются сроки, но после прочтения Вашей статьи этот процент не уменьшится ни на йоту. Потому что вы не предлагаете решение. Разбить ТЗ на блоки или умножить время на 1.2, извините, но это же и так очевидно, имхо.
3. Вау! Класс! Книжки! Куча! Управление проектами! Ссылки? Авторы? Названия? Ну вы понимаете, о чем я...
Не сочтите, меня за толстого тролля, но в этой статье нет ничего. Вместо абстрактных подсчетов стоимости проекта и процентов взятых с потолка приведите один пример. Понятное дело, что реальные ТЗ выкладывать сюда не стоит, но давайте вместе придумаем какой нибудь example.com, сроки которого сколько-то месяцев, а функциональность размазана на столько-то блоков? Расскажите, как правильно вытащить из заказчика всю нужную информацию за минимальное количество итераций. Поведайте о том, как добиться лучшего понимания у заказчика в вопросах взаимодействия различных частей проекта, чтобы когда на середине в его буйную голову постучится дрозд он осознавал какой объем работ придется переделывать. Как вовлечь заказчика в процесс разработки с целью получения быстрого отклика на неочевидные моменты реализации? Спасибо.
1. Где картинки? Хоть одна. Хотя бы рядом с PERT диаграммой.
2. В чем состоит цель вашей статьи? 95% ваших читателей фейлят проекты потому что срываются сроки, но после прочтения Вашей статьи этот процент не уменьшится ни на йоту. Потому что вы не предлагаете решение. Разбить ТЗ на блоки или умножить время на 1.2, извините, но это же и так очевидно, имхо.
Статистику взял из кучи книг по управлению проектов, которые пришлось перелопатить.
3. Вау! Класс! Книжки! Куча! Управление проектами! Ссылки? Авторы? Названия? Ну вы понимаете, о чем я...
Не сочтите, меня за толстого тролля, но в этой статье нет ничего. Вместо абстрактных подсчетов стоимости проекта и процентов взятых с потолка приведите один пример. Понятное дело, что реальные ТЗ выкладывать сюда не стоит, но давайте вместе придумаем какой нибудь example.com, сроки которого сколько-то месяцев, а функциональность размазана на столько-то блоков? Расскажите, как правильно вытащить из заказчика всю нужную информацию за минимальное количество итераций. Поведайте о том, как добиться лучшего понимания у заказчика в вопросах взаимодействия различных частей проекта, чтобы когда на середине в его буйную голову постучится дрозд он осознавал какой объем работ придется переделывать. Как вовлечь заказчика в процесс разработки с целью получения быстрого отклика на неочевидные моменты реализации? Спасибо.
На то часть и первая. Извините, но за время своей работы я столько раз сталкивался с тем, что даже при очевидной проблеме со стороны исполнителя, не говоря уж о том, что есть не столь очевидные, заставить человека сказать «да, это мой косяк, давай подумаем что делать с этим дальше» настолько трудно, что иногда просто за голову берешься. Этой вводной частью я пытался достучаться до тех, кто в танке. До тех, кто готов винить что угодно и кого угодно, лишь бы не признавать того, что главная причина всех бед — он сам.
Написать статью на тему «ох какие заказчики скоты»? Неа, не скоты.
Привести пример? Будет пример, обязательно будет. Только дайте войти в процесс. Когда то меня до скрежета зубовного за… ло, что почти все проекты не заканчиваются в срок и выходят за рамки бюджета. И я стал думать, анализировать, читать. Хотите чтобы я в рамках одной статьи рассказал как все будет круто и как делать? Не могу. Не получится. Ибо мысли, которые я озвучивал с коллегами еще год назад, подозрительно перекликаются с тем, к чему я пришел. А толку? Пока не прожевал, пока все не озвучил — нифига не работало.
Потому и статьи будут размазаны на несколько, уж извините.
Ну а что касается картинок, то как то не привык, что ли :) Тут уж извините :)
Написать статью на тему «ох какие заказчики скоты»? Неа, не скоты.
Привести пример? Будет пример, обязательно будет. Только дайте войти в процесс. Когда то меня до скрежета зубовного за… ло, что почти все проекты не заканчиваются в срок и выходят за рамки бюджета. И я стал думать, анализировать, читать. Хотите чтобы я в рамках одной статьи рассказал как все будет круто и как делать? Не могу. Не получится. Ибо мысли, которые я озвучивал с коллегами еще год назад, подозрительно перекликаются с тем, к чему я пришел. А толку? Пока не прожевал, пока все не озвучил — нифига не работало.
Потому и статьи будут размазаны на несколько, уж извините.
Ну а что касается картинок, то как то не привык, что ли :) Тут уж извините :)
Спасибо. В любом случае статья получилась интересной и я с удовольствием осознал что большинство из ваших мыслей мне близки, и до идей которые вы излагаете так или иначе я тоже дошел в процессе своей работы.
Вы совершенно правы, они не скоты. Несомненно иногда проскакивают совсем уж лиственные породы деревьев, но в общем массе они знают чего хотят и требуют бережно относиться к их идеям и мыслям. О том, как отказываться от работы с заказчиком, потому что он бревно, и никакими разумными издержками этого не покрыть, я думаю вы тоже упомянете где нибудь (раз уж диалог с читателями планирует быть долгим :), но это тема для отдельного обсуждения.
Мне же хотелось дать вам обратную связь, чтобы следующие части были более структурированы, логичны и наполнены картинками и примерами. Я не зря делаю акцент на картинках, к которым вы как-то не привыкли: ) Читать полотна текста, пусть и написанного самым лучших рассказчиком, очень утомительно. Картинки разряжают текст, дают возможность глазам отдохнуть чуть чуть перед новым погружением в пучины ваших размышлений. Не говоря уже о том, что информацию можно представлять в различных формах, и иногда выбор удачной формы влечет за собой лучшее понимание содержания.
Вы совершенно правы, они не скоты. Несомненно иногда проскакивают совсем уж лиственные породы деревьев, но в общем массе они знают чего хотят и требуют бережно относиться к их идеям и мыслям. О том, как отказываться от работы с заказчиком, потому что он бревно, и никакими разумными издержками этого не покрыть, я думаю вы тоже упомянете где нибудь (раз уж диалог с читателями планирует быть долгим :), но это тема для отдельного обсуждения.
Мне же хотелось дать вам обратную связь, чтобы следующие части были более структурированы, логичны и наполнены картинками и примерами. Я не зря делаю акцент на картинках, к которым вы как-то не привыкли: ) Читать полотна текста, пусть и написанного самым лучших рассказчиком, очень утомительно. Картинки разряжают текст, дают возможность глазам отдохнуть чуть чуть перед новым погружением в пучины ваших размышлений. Не говоря уже о том, что информацию можно представлять в различных формах, и иногда выбор удачной формы влечет за собой лучшее понимание содержания.
UFO just landed and posted this here
На интуите есть хорошая книга по теме "Компонентный подход в программировании".
Правда, она с уклоном на Java и NET, но тем не менее есть что почерпнуть и разработчикам использующим другие ЯП.
Правда, она с уклоном на Java и NET, но тем не менее есть что почерпнуть и разработчикам использующим другие ЯП.
Sign up to leave a comment.
Фриланс как средство заработка. Ч.1. Старт проекта