Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
Мда, Вам еще осваивать и осваивать лексикон-то :)
Отсутствие опыта и знаний всего лишь увеличивают риски при планировании и уменьшают вероятность выполнения планов в заданных параметрах. Это всего лишь надо учитывать в необходимых мероприятиях по реагированию на риски… ну и так далее :)
Без плана иногда никак нельзя. Потому что многие люди работают не «от сих», а «до сих» — для них очень важно иметь дедлайн — он их мобилизует и пропинывает. Иногда без плана просто невозможно — при выделении бюджета например, наборе команды — очень сложно впоследствии добавлять членов команды. В общем лучше иметь план воздушный, основанный на многих неопределенностях, чем просто от балды.
А то о чем Вы говорите это не планирование а коммуникации. В общем учите матчасть.
Отсутствие опыта и знаний всего лишь увеличивают риски при планировании и уменьшают вероятность выполнения планов в заданных параметрах. Это всего лишь надо учитывать в необходимых мероприятиях по реагированию на риски… ну и так далее :)
Без плана иногда никак нельзя. Потому что многие люди работают не «от сих», а «до сих» — для них очень важно иметь дедлайн — он их мобилизует и пропинывает. Иногда без плана просто невозможно — при выделении бюджета например, наборе команды — очень сложно впоследствии добавлять членов команды. В общем лучше иметь план воздушный, основанный на многих неопределенностях, чем просто от балды.
А то о чем Вы говорите это не планирование а коммуникации. В общем учите матчасть.
По-моему, мне повезло — мы всегда занимались чем-то новым, изобретали свои собственные велосипеды. Наверное, я погорячился, говоря, что от планов нужно отказываться. Например, сегодня у нас план — запустить очередную версию приложения на тестовых серверах. После этого запуска уже известны задачи, которыми нам следует заняться в первую очередь. Но отсутствует предопределенность что ли, мы занимаемся вещами, необходимость которых сами остро осознаем. Каждый из нас.
По поводу матчасти — я только рад, что нахожусь в самом начале пути. Так что, в общем, учу :)
Спасибо!
По поводу матчасти — я только рад, что нахожусь в самом начале пути. Так что, в общем, учу :)
Спасибо!
нельзя планировать то, чего ты еще никогда не делал
— если дискретизировать задачу до элементарных вещей, то их по отдельности можно легко спланировать, а все результаты суммировать, потом умножить на рандомный коэф. в промежутке 2...5 и можно сообщать оценку инвестору.
Запомните, чем меньше задача, тем меньше шанс, что вы (или ваши подчиненные) ее профакапят.
Ну и бонус: youtube.com/watch?v=X1c2--sP3o0&feature=player_embedded
П.С. Читайте про управление софтверными проектами.
— если дискретизировать задачу до элементарных вещей, то их по отдельности можно легко спланировать, а все результаты суммировать, потом умножить на рандомный коэф. в промежутке 2...5 и можно сообщать оценку инвестору.
Запомните, чем меньше задача, тем меньше шанс, что вы (или ваши подчиненные) ее профакапят.
Ну и бонус: youtube.com/watch?v=X1c2--sP3o0&feature=player_embedded
П.С. Читайте про управление софтверными проектами.
По моему это скорее вы говорите о коммуникациях вместо планирования, приводя дедлайны в качестве дополнительной мотивации. Призыв «учить матчасть» из ваших уст звучит весьма самонадеянно, ибо автор во многом прав.
Про дедлайны Вы конечно правы, хотя проекты такая вещь — планирование переходит в коммуникации, переходящие в контроль, качество и так далее по тексту.
Автор был бы прав если понимал в чем. Что бы что-то ломать, надо это сначала сделать как написано, потом как надо, отбить на этом все нежные части тела, проникнуться и осознать зачем это, когда нужно, а когда не очень. И только тогда со всей ответственностью, четко понимаю что теряешь и что приобретаешь, можно ломать под себя.
Автор был бы прав если понимал в чем. Что бы что-то ломать, надо это сначала сделать как написано, потом как надо, отбить на этом все нежные части тела, проникнуться и осознать зачем это, когда нужно, а когда не очень. И только тогда со всей ответственностью, четко понимаю что теряешь и что приобретаешь, можно ломать под себя.
А вы считаете, что я совсем зеленый? Зря. Я довольно самокритично отношусь к себе, поэтому осознание, что мне не хватает опыта, двигает вперед.
Ломать начал именно потому, что так, как написано — не сработало.
Ломать начал именно потому, что так, как написано — не сработало.
Нее, зеленые двигают более радикальные идеи :)
А что из написанного не сработало?
А что из написанного не сработало?
В предыдущем аналогичном проекте досталось большое количество разрозненного кода и пачка дыр, в том числе в финансовой системе. Планы строились хоть и весьма детализированные, но слишком далекие. Вместо этого надо было забить на все и на всех, и тупо сделать то, чего с самого начала не хватало.
В итоге техническая часть изрядно отстала от намеченного, сроки постоянно срывались. Ну, а когда закончились деньги, проект распался.
В итоге техническая часть изрядно отстала от намеченного, сроки постоянно срывались. Ну, а когда закончились деньги, проект распался.
Вот вы сделали как написано, теперь пора сделать как надо :)
>Планы строились хоть и весьма детализированные, но слишком далекие. Вместо этого надо было забить на все и на всех, и тупо сделать то, чего с самого начала не хватало.
То есть взяли и придумали то что будете делать, а необходимое просто проигнорировали? :)
Или просто со временем представление о необходимом поменялось, а того человека, который управляет проектом уведомить забыли?
>В итоге техническая часть изрядно отстала от намеченного, сроки постоянно срывались. Ну, а когда закончились деньги, проект распался.
Я правильно понимаю что однажды написанные планы были залакированы и выставлены в красном углу как иконостас?
По двум словам конечно никогда проект на осознать, но смутное впечатление что то, что было сделано, было сделано для галочки и к проектному управлению не имеет никого отношения.
>Планы строились хоть и весьма детализированные, но слишком далекие. Вместо этого надо было забить на все и на всех, и тупо сделать то, чего с самого начала не хватало.
То есть взяли и придумали то что будете делать, а необходимое просто проигнорировали? :)
Или просто со временем представление о необходимом поменялось, а того человека, который управляет проектом уведомить забыли?
>В итоге техническая часть изрядно отстала от намеченного, сроки постоянно срывались. Ну, а когда закончились деньги, проект распался.
Я правильно понимаю что однажды написанные планы были залакированы и выставлены в красном углу как иконостас?
По двум словам конечно никогда проект на осознать, но смутное впечатление что то, что было сделано, было сделано для галочки и к проектному управлению не имеет никого отношения.
> Автор был бы прав если понимал в чем.
— планирование основывается на прогнозировании. Прогнозирование — на опыте, конъюнктуре, доступной глубине анализа. Краткосрочное прогнозирование всегда эффективнее долгосрочного. Предпочтение более эффективного метода — всегда рационально. Вот о чем пишет автор, и он полностью прав. Любое планирование в области низкой плотности и четкости данных — это формализм и очковтирательство.
— планирование основывается на прогнозировании. Прогнозирование — на опыте, конъюнктуре, доступной глубине анализа. Краткосрочное прогнозирование всегда эффективнее долгосрочного. Предпочтение более эффективного метода — всегда рационально. Вот о чем пишет автор, и он полностью прав. Любое планирование в области низкой плотности и четкости данных — это формализм и очковтирательство.
не совсем так.
Прогнозы имеют допущения и ограничения, которые имеют свойство не выполняться и превышаться. И когда это происходит надо пересматривать и менять все проектные данные.
Я повторюсь — планировать можно всегда, вопрос лишь в точности или вероятности выполнения этих планов. Но связывать воедино все параметры проекта необходимо.
Прогнозы имеют допущения и ограничения, которые имеют свойство не выполняться и превышаться. И когда это происходит надо пересматривать и менять все проектные данные.
Я повторюсь — планировать можно всегда, вопрос лишь в точности или вероятности выполнения этих планов. Но связывать воедино все параметры проекта необходимо.
>Сейчас моим лозунгом, не оправданием, а именно лозунгом становится фраза: «нельзя планировать то, чего ты еще никогда не делал».
Почему лозунг ??? Если его как презерватив — один раз использовал и выкинул (второй раз уже «никогда не делал» будет неприменимо), а вы с ним по жизни шагать собрались?
Почему лозунг ??? Если его как презерватив — один раз использовал и выкинул (второй раз уже «никогда не делал» будет неприменимо), а вы с ним по жизни шагать собрались?
Второй раз «никогда не делал» будет как раз применимо, поскольку я не собираюсь поднимать одно и то же дело дважды, это попросту не интересно. Придумав себе потенциально успешное дело, я вновь столкнусь с этим самым незнанием. Да, опыта будет больше, технически подкованная команда не подведет, но я не об этом. Мы все равно изобретаем что-то для нас уж точно совершенно новое.
Что же вы такое делали, если не секрет, что «еще никогда не делали»? Обычная практика — на проекте иметь нужное количество экспертов в профильных областях, которые УЖЕ решали подобные задачи и знают, хотя бы примерно, что и как будет делаться.
Мы делаем рекламную сеть, заточенную под видео. У меня есть опыт построения рекламных сетей вообще, но с именно с видео до этого проекта никто из команды плотно не работал. То же касается многими нелюбимого flash (про говорить пока рано), на котором никто из нас раньше не писал. Даже дба пришлось сменить привычный mssql, благо диалектов sql не так много.
Парсер съел тэг video. Про html5 говорить пока рановато, хотя правильные мысли по этому поводу уже появляются.
И что мешало нанять в команду специалиста по flash и видео?
А зачем? В самом начале, только когда ко мне, как говорится, «приехала» идея сделать нечто подобное, я опять же планировал, что для разработки нужен специалист по flash, doom-программист на javascript, гуру в кодировании видео.
На практике получается, что на flash сейчас тратится настолько мало времени, что поиск нового человека, связанные с этим затраты (не только денег, но и моего времени), не оправданы. В итоге у нас есть программист, уже разбирающийся в технологии на достаточном уровне, при этом его профиль — вообще питон. И это все при том, что возможности нанять нового человека может и не быть (либо для этого придется пожертвовать старым).
По поводу видео вы, возможно, правы. Но с этим мне может помочь друг, который на видео собаку съел, поэтому проблем пока не возникло.
На практике получается, что на flash сейчас тратится настолько мало времени, что поиск нового человека, связанные с этим затраты (не только денег, но и моего времени), не оправданы. В итоге у нас есть программист, уже разбирающийся в технологии на достаточном уровне, при этом его профиль — вообще питон. И это все при том, что возможности нанять нового человека может и не быть (либо для этого придется пожертвовать старым).
По поводу видео вы, возможно, правы. Но с этим мне может помочь друг, который на видео собаку съел, поэтому проблем пока не возникло.
А зачем?
Чтобы спрогнозировать сроки, предсказать технические проблемы и выбрать правильную архитектуру. Если бюджетом не предусмотрено, я в таких случаях нанимаю консультанта. За день-два они не дорого берут, можно в несколько сот долларов уложиться.
Это вообще что-то заоблачное. Подскажите, как консультанту прогнозировать сроки для других людей, с опытом и навыками, даже с личными качествами которых он не знаком? И что потом с этими прогнозами делать?
По поводу технических проблем и (с оговорками) архитектуры — соглашусь.
По поводу технических проблем и (с оговорками) архитектуры — соглашусь.
Очень просто — консультант определяет трудоемкость. Вот недавно из практики — встал вопрос о портировании некоего проекта на ubuntu. Там был момент в интеграции с virtualbox, по поводу которого моя квалификация не позволяла провести оценки — я не был знаком с XPCOM. привлек консультанта. Консультант посмотрел на код, посмотрел что нужно и сказал что сделать это конечно можно, но потребуется то-то и то-то. Где-то на месяц-два работы. А я надеялся, что можно максимум за неделю сделать. Соответственно — пересмотрел концепцию.
По поводу идеи и её стоимости в ломаный грош: а как конкурировать гаражному стартапу с «монстрами» рынка, если ваша идея их «цепанет» а участвовать в её реализации на ваших условиях они не соизволят? Ох, не все тут так однозначно.
Показывать или не показывать план команде (на месяц и более) — это ваше решение (в частности, в зависимости от того, насколько он потом выполняется). Но планировать необходимо (хотя бы для выявления новых задач и нестыковок). Так же публичный план хотя бы на неделю нужно иметь (это у вас в каком-то виде, судя по комментариям есть).
Можно планировать то что никогда не делал. Используйте относительные оценки «сложности задач». т.н. story points. Делайте короткие итерации. Считайте velocity команды и вносите поправки. Рисуйте burndown — и очень скоро вы начнете представлять в какой срок и ресурсы в итоге уложится ваш проект.
Не стоит возводить в абсолют отказ от плана, так же как и не стоит абсолютизировать планирование.
Если подробное планирование не подходит — скорее-всего подойдет что-нибудь из agile. Процесс планирования следует сделать таким, что бы он не был обузой.
Не стоит возводить в абсолют отказ от плана, так же как и не стоит абсолютизировать планирование.
Если подробное планирование не подходит — скорее-всего подойдет что-нибудь из agile. Процесс планирования следует сделать таким, что бы он не был обузой.
Сейчас моим лозунгом, не оправданием, а именно лозунгом становится фраза: «нельзя планировать то, чего ты еще никогда не делал».
Наверное, очень многие руководители проектов и тимлиды проходят через это. Сначала вера в абсолютность планирования, потом разочарование и полное отрицание какой-то пользы от него. Я тоже проходил. :)
Может быть, вы согласитесь с такими оговорками:
— Можно и нужно планировать то, чего ты никогда не делал, но этот план нужно периодически пересматривать. Начал реализовывать план — глядишь, через месяц обнаруживается, что ты уже кое-что делал, и этот опыт можно учесть при пересмотре плана. А к концу проекта получается, что ты уже всё это делал. :)
— При планировании того, чего ты никогда не делал, имеет смысл обратиться за помощью к человеку, который уже делал это или что-то похожее. И этот человек наверняка уже находится в твоей команде. А значит, планировать лучше всей командой.
Соглашусь, но не полностью :). Я оговорился, что условия у нас почти схожи с гаражными. Руководство все же не сильно радужно реагирует на пересмотры сроков в большую сторону. Да, в основном мы планируем командой, но демократию особо не устраиваем. Как промежуточный результат — несколько великолепных идей, до которых я вряд ли быстро дошел бы сам, уже обсуждены и внедрены.
Ну, я на вопрос «когда сможем?» обычно отвечаю вопросом «а когда надо?» После чего начинаем думать, что мы можем успеть к названному сроку, разбиваем разработку на понятные этапы, и каждому этапу даём оценку (особенно хорошо получается с Planning Poker). Но обязательно по завершении каждого этапа нужно пересматривать план «с учётом вновь открывшихся обстоятельств».
Умные люди, давно прошедшие по всем этим граблям, разработали практики Agile — scrum-митинги, итерации, ретроспективы — и соответствующие инструменты: доска задач, burndown диаграмма (до сих пор не нашёл адекватного перевода на русский язык). Всё это имеет смысл пробовать, что не приживётся — отбрасывать, что понравится — использовать.
И, конечно, такой подход требует определённого доверия между руководителем разработки и тем, кто даёт ответ на вопрос «когда надо». Ответ «вчера» в этом случае бесполезен.
Умные люди, давно прошедшие по всем этим граблям, разработали практики Agile — scrum-митинги, итерации, ретроспективы — и соответствующие инструменты: доска задач, burndown диаграмма (до сих пор не нашёл адекватного перевода на русский язык). Всё это имеет смысл пробовать, что не приживётся — отбрасывать, что понравится — использовать.
И, конечно, такой подход требует определённого доверия между руководителем разработки и тем, кто даёт ответ на вопрос «когда надо». Ответ «вчера» в этом случае бесполезен.
Отлично написали! спасибо!
Планирование разработки эффективно только в краткосрочных периодах. Совсем не планировать могут только высокослаженные команды. Они и так знают, что им надо сделать, и когда. И для этого вообще не нужен ПМ.
Они и так знают, что им надо сделать, и когда. И для этого вообще не нужен ПМ.
— Это заблуждение. Если даже нет выделенного ПМ, то нужен кто-то, кто возьмет его обязанности (а ПМ это не только ценный ме^W контроль и раздача работы, это прежде всего адаптер между заком и Командой) на себя.
— Это заблуждение. Если даже нет выделенного ПМ, то нужен кто-то, кто возьмет его обязанности (а ПМ это не только ценный ме^W контроль и раздача работы, это прежде всего адаптер между заком и Командой) на себя.
Это не заблуждение. Разделите команду разрабов и команду продажников. Постройте протокол передачи информации между этими двумя командами в информативной, а не приказной форме. Это значит, что сейлсы принимают решение самостоятельно, продавать им некий продукт, или нет. А разработчики принимают решение что-то делать в зависимости от того, какая у них загрузка сейчас. Добавьте в эту схему немного сдельщины и бонусов за выработку, и получите схему, где ПМ будет вырожден в одного из продажников, а решение о начале разработки принимает один из команды. Можно по очереди предоставлять разработчикам право выбирать сливки или интересные проекты.
ПМ в его идеальной форме всего лишь почтальон, который перекладывает письма из одной стопочки в другую и наоборот. Скрипач не нужен © Кин-дза-дза
ПМ в его идеальной форме всего лишь почтальон, который перекладывает письма из одной стопочки в другую и наоборот. Скрипач не нужен © Кин-дза-дза
О том что не стоит все жестко планировать многократно описано в книгах про Agile. Не сочтите за оскорбление, но вы изобрели велосипед.
Поделитесь, в какую сторону двигаться, раз вы узнали этой мой велосипед.
Автор поста, думаю, не обидится, если я отвечу. Прочитать книжки по XP (экстремальное программирование)
См. agile-манифест agilemanifesto.org/
Также про гибкую методологию разработки.
ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8
Бережливое программирование
www.poppendieck.com/lean.htm
Также про гибкую методологию разработки.
ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8
Бережливое программирование
www.poppendieck.com/lean.htm
В Rework они выступают против планирования называя его догадками, но и против частых совещаний, заменяя их обязательным общением в команде, которая тоже должна быть максимально компактной, т.е. без излишеств. Такой подход позволяет как раз и сосредоточится на работе. Но понятно, что даже список дел — это уже некий план действий.
Да уж. Как планировать не зная, сколько выполняется тот или иной этап — не понятно.
Ваши слова бы, да многим руководителям!
А есть риск, что без плана не будет и результата?
Ваши слова бы, да многим руководителям!
А есть риск, что без плана не будет и результата?
Конечно. Все зависит от качества моей собственной работы, тут-то я как раз и отвечаю перед руководством и заказчиками.
Мне в голову приходит разница определений творчества и креатива. Творчество — это хаос, поток сознания. Креатив — упорядоченное творчество. И отчего-то мне кажется, что использование планов в работе и отказ от их использования похоже на эти определения. Плановая работа — креатив, работа без планов — творчество.
И знаете, необходимо обладать действительно высоким уровнем самоорганизации, ответственности и понимания ситуации, чтобы творить (работать без планов). Я прям поздравляю Вас, что вы встали на этот путь! У меня самой не получается никак.
И знаете, необходимо обладать действительно высоким уровнем самоорганизации, ответственности и понимания ситуации, чтобы творить (работать без планов). Я прям поздравляю Вас, что вы встали на этот путь! У меня самой не получается никак.
Мне в голову приходит разница определений творчества и креатива. Творчество — это хаос, поток сознания. Креатив — упорядоченное творчество. И отчего-то мне кажется, что использование планов в работе и отказ от их использования похоже на эти определения. Плановая работа — креатив, работа без планов — творчество.
И знаете, необходимо обладать действительно высоким уровнем самоорганизации, ответственности и понимания ситуации, чтобы творить (работать без планов). Я прям поздравляю Вас, что вы встали на этот путь! У меня самой не получается никак.
И знаете, необходимо обладать действительно высоким уровнем самоорганизации, ответственности и понимания ситуации, чтобы творить (работать без планов). Я прям поздравляю Вас, что вы встали на этот путь! У меня самой не получается никак.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не планом единым