Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 89
Спасибо!
Просто, красиво, кратко, понятно — почти идеальный пример.
День 6 — Жизненно.
Полтора, как и три, как и прочее число — это очень средняя температура по больнице. По своему опыту разработчика, могу сказать, что я всегда оцениваю сроки сверху. Типа 30 минут — 4 часа. И чаще всего в них заведомо укладываюсь. В то же самое время, если я упустил какие-то архитектурные детали, то срок этот может на порядок возрасти даже от моих пессимистических оценок.
А ещё, время = деньги. Т.е. Если мы умножаем оценку времени на порядок, по сути на порядок мы умножаем и стоимость проекта для заказчика. В этом случае он может выбрать другую контору, которая прикидывает затраты более точно.
… которая прикидывает затраты более оптимистично. Потом 70% что заплатит больше, чем выставляли ценник мы. Но а) откуда заказчик сразу узнает, что мы лучше укладываемся в сроки и бюджеты и не косячим? б) 70% != 100%, заказчик халяву любит, есть задняя мысль, что можно будет «нагнуть» подрядчика на бесплатную доп.работу из-за туманности ТЗ и прочих подобных факторов в) потом — не сейчас, психологически (и организационно) проще заплатить больше, но за несколько раз и «неожиданно», заказчику остаётся поле для манёвра г) может быть, что всплывёт, что заказчику сойдёт продукт и половинного качества, или что он ему вообще нафиг не нужен.
Так что реально «мы» предлагаем «водопад», а «другая контора» — метод более коротких итераций…
Так что реально «мы» предлагаем «водопад», а «другая контора» — метод более коротких итераций…
Не искажайте мои слова. Вы ведь не считаете себя супер-специалистом во всех вопросах. так что попробуйте предположить, что существует компания, которая лучше Вас разберается в некой разработке, и может выставить сроки более точно, чем Ваше «послушай программиста и умнож на число с потолка».
Кстати, хороший тест команды. Спросить как они оценивают сроки. Если слышите что-то типа «ну мы спрашиваем наших программистов, они дают оценку сроков, плюс мы закладываем время на случай непредвиденных ситуаций» — бегите от такой команды куда подальше.
Ну а метод коротких итераций в любом случае лучше водопада, особенно когда заказчик чётко не знает чего хочет.
Кстати, хороший тест команды. Спросить как они оценивают сроки. Если слышите что-то типа «ну мы спрашиваем наших программистов, они дают оценку сроков, плюс мы закладываем время на случай непредвиденных ситуаций» — бегите от такой команды куда подальше.
Ну а метод коротких итераций в любом случае лучше водопада, особенно когда заказчик чётко не знает чего хочет.
Спросить как они оценивают сроки.Т.е. 70%, что попросить разгласить коммерческую тайну, если это не ваша же контора… такое не «спрашивают», а шпионят.
Не искажайте мои слова.Более оптимистические оценки могут оказаться менее точными ;-) но при этом более привлекательными для заказчика ;-)
существует компания, которая лучше Вас разбирается в некой разработке, и может выставить сроки более точно, чем Ваше «послушай программиста и умножь на число с потолка».Сомневаюсь. Иначе подрабатывали бы консалтингом в деле оценки и экспертизы проектов, а не разрабатывали бы сами;-) Хотя всё бывает. И для пиара покатит))
Т.е. 70%, что попросить разгласить коммерческую тайну, если это не ваша же контора… такое не «спрашивают», а шпионят.
Интересно, почему ваше «правило потолка» генерирует число 70%. По теме — за спрос Вас не побьют. Да и честно говоря, никакая это не тайна. Если компания пытается «сьехать» с ответа — тоже сигнал что это какие-то студенты. Которые про хорошие методики управления командами даже не читали.
Вы уверены, что более низкие оценки, чем ваши — будут провальными для команды. Это не всегда так. Особенно если Вы выставляете сроки от потолка. Скорее это похоже на оправдание себя — «Мы выставили сроки и цену которая точно прикрывает нашу задницу (хотя точно оценить проект мы не можем), все остальные идиоты»
Сомневаюсь. Иначе подрабатывали бы консалтингом в деле оценки и экспертизы проектов, а не разрабатывали бы сами;-) Хотя всё бывает. И для пиара покатит))
У Вас высокая самооценка. А насчёт консалтинга и разработки — я не знаю ни одной консалтинговой IT фирмы, с доходами, сравнимыми с доходами MS, Google или Apple. Что наталкивает на мысль, что разрабатывать всё же более выгодно.
Интересно, почему ваше «правило потолка» генерирует число 70%«Скорее всего так, но иногда всякое бывает»
У Вас высокая самооценка."Я ещё никогда не слышал, чтоб кого-то так изысканно посылали на х..." Спасибо, я заучу эту формулировку;-)
Раплывчатое, мутное ТЗ — косяк РП.
Если ТЗ утверждено программистами и заказчиком, правки невозможны.
В формировке четкого ТЗ и заключается одна из основных задач РП.
Если ТЗ утверждено программистами и заказчиком, правки невозможны.
В формировке четкого ТЗ и заключается одна из основных задач РП.
Но бывает, что программист оценил сверху, РП оценил сверху, в итоге сумма=сроки утраиваются, а то и больше. А это печально сказывается на лояльности заказчика.
Кстати, утроение названного исполнителем срока — не такая уж редкость. Это может спугнуть заказчика, если заказ ещё не получен, особенно если оптата почасовая. А так — финальное впечатление важнее вдохновления обещаниями. Закзачик строит свои планы относительно названных сроков, поэтому начальное разочарование названными сроками с лихвой покрывается эффектом от своевременного (особенно досрочного) выполнения, в противовес запозданию и невыполнению обещаний. И заказчик уходит довольным.
Что-то я никогда не слышал о досрочном выполнении IT-проектов. В вашей практике такое было?
Было. Изначально доработка оценивалась в 4 месяца с 3 этапами + тестирование по каждому. Заказчика это устроило. Но через 2 месяца мы уже перешли к выполнению 3го этапа без особых проблем. Перед озвучиванием новости об опережении сроков мы наступили на небольшие грабли, но в итоге доработка была проведена на 1,5 месяца раньше сроков, чему заказчик оказался несказанно рад, проигнорировав последующие задержки по другим проектам.
Разумеется. Ситуацию спасал как раз «буфер времени».
Было. И как раз это было, когда проект делал 1 (я) или 2 человека. А поэтому не было этих схем и управления процессом. Некем было управлять, а значит на каждом шаге определялось наиболее оптимальное направление. Но сроки указывали с буфером
А почему здесь никто не вспоминает о конкуренции — о том, что назвав такую сумму — с большой вероятностью договор не будет заключен?
Не всегда конкуренция — это только стоимость продукта. Нужно учитывать специфику работы компании. Вдруг с этим заказчиком уже сложились успешные отношения, вдруг уже есть рабочие проекты? А если обращение по рекомендации? Или в рамках гораздо более крупного проекта, то есть выгодно заключать договор только с компанией N?
Конкурентная борьба ведётся не только ценой. Если заказчик давно работает с исполнителем или его привело «сарафанное радио», цена уже не является решающим фактором для заключения договора.
Именно поэтому РП должен думать не только о сроках и компании но и уметь мыслить категориями Бизнеса.
… а ещё уметь сделать продукт в одну харю в те же самые сроки;-)
Должен быть кто-то, кто умеет мыслить категориями бизнеса, но почему это должен быть именно PM?
Должен быть кто-то, кто умеет мыслить категориями бизнеса, но почему это должен быть именно PM?
Потому что хороший РП должен хотеть вырасти в техдиректора, например :)
эээ, тоесть есть программисты/тестеры/дизайнеры, есть PM, есть «тот-кто-мыслит-категориями-бизнесса». И есть заказчик, в конце-концов. Знаете, по моему они никогда не договорятся. Слишком много народа :-)
Для команды РП — представитель заказчика и действует в интересах заказчика, для заказчика — представитель компании (команды) и действует в интересах компании (команды).
Ну стоит заметить, что разделение интересов на «Интересы команды» и «Интересы заказчика» — уже беда. Ведь цель у них одна — создать качественный продукт. А значит и интересы должны быть общими. Таким образом, РП (о боже, минут 10 не мог понять, что это сокращение значит, привык к забугорному PM) представляет интересы проекта.
Но, очевидно кроме собственно проекта, должны быть финансовые интересы фирмы и заказчика. И эти вопросы должны быть изолированны от команды. Хотя в небольших проектах, Руководитель проекта часто совмещает должности собственно PM и переговорщика с заказчиком. Но как известно, проще найти двух людей, один из которых будет хорошим PM а второй — хорошим переговорщиком, чем искать человека-оркестр.
Но, очевидно кроме собственно проекта, должны быть финансовые интересы фирмы и заказчика. И эти вопросы должны быть изолированны от команды. Хотя в небольших проектах, Руководитель проекта часто совмещает должности собственно PM и переговорщика с заказчиком. Но как известно, проще найти двух людей, один из которых будет хорошим PM а второй — хорошим переговорщиком, чем искать человека-оркестр.
Сроки, названные программистом, нужно делить на ноль.
То есть Вы предлагаете самостоятельно оценивать сроки, без участия программиста?
Сроки названные программистом — ничего не значат. У него настроение сегодня плохое (Сроки большие). А вот завтра будет хорошим, и сроки резко ужмутся. А вот оценка сложности — уже важная вещь. На основе которой Вы можете прогнозировать время выполнения задачи.
Простой пример — есть тех. характеристики машины, сколько она тратит в городском/загородном режиме. Есть показания бортового компьютера. Есть растояние в километрах. Но только Вы, оценив маршрут до цели, свой стиль вождения и загрузку дорог можете прикинуть, сколько бензина Вам понадобится.
Простой пример — есть тех. характеристики машины, сколько она тратит в городском/загородном режиме. Есть показания бортового компьютера. Есть растояние в километрах. Но только Вы, оценив маршрут до цели, свой стиль вождения и загрузку дорог можете прикинуть, сколько бензина Вам понадобится.
Здорово. Только пока вы проектируете (да даже велосипед) и тянете с указанием сроков, заказчик уже уйдет к Саше из другой конторы, который съев собаку на строительстве велосипедов, экспертно оценит сроки и прикинет, сколко это будет стоить с точностью 33%. Чего для болшинства заказчиков будет вполне достаточно.
Возможно. Но думаю день на предварительное проектирование и планирование вам всегда дадут. Какое-то представление о сроках уже можно будет получить.
Вот и получается, что ты сидишь, проектируешь, планируешь… А потом оказывается, что заказчик рассчитывал на сумму в 4 раза меньше, чем ты посчитал, исходя из времени, которую надо затратить на проект.
И выходит, что день проработал зря, без всякой пользы, ничего не заработав.
И выходит, что день проработал зря, без всякой пользы, ничего не заработав.
Что ж вы предлагаете любой ценой заманивать заказчика, неважно справитесь ли с проектом за предложенные деньги?
Не столь категорично. Если кусок не по зубам, зачем пытаться «понадкусывать»?
А с другой стороны, кто не рискует…
А с другой стороны, кто не рискует…
Есть такая тактика. А потом раскручивать на доп. бабло. «Метод коротких итераций» (vs «водопад») в применении к более высокому уровню;-)
Я ничего не предлагал. Хотел узнать мнение более опытных коллег.
Как один из вариантов, который мне предлагали — это составление ТЗ за отдельную плату. Но есть смутные доводы, что кто-то вообще решиться платить за ТЗ не увидив самого ТЗ )).
Для себя пока избрал тактику называть заказчику минимальную цену, от которой мы будем работать для него. Так сразу отсеиваются те, кто хочет интернет-магазин за 20 т.р. В итоге не трачу на нищебр… несостоятельных людей свое время.
Но, хочется верить, что есть способы мудрее.
Как один из вариантов, который мне предлагали — это составление ТЗ за отдельную плату. Но есть смутные доводы, что кто-то вообще решиться платить за ТЗ не увидив самого ТЗ )).
Для себя пока избрал тактику называть заказчику минимальную цену, от которой мы будем работать для него. Так сразу отсеиваются те, кто хочет интернет-магазин за 20 т.р. В итоге не трачу на нищебр… несостоятельных людей свое время.
Но, хочется верить, что есть способы мудрее.
Вот именно для этого нужны предварительные оценки, «на глаз».
Без всякой пользы невозможно. Вы оценили, подумали, представили, создали черновик плана, еще что-нибудь. А заказчик ушел. Зато в следующий раз столкнувшись с подобным проектом Вы будете меньше и быстрее думать, по-другому будете говорить с заказчиком и он не уйдет.
Без всякой пользы невозможно. Вы оценили, подумали, представили, создали черновик плана, еще что-нибудь. А заказчик ушел. Зато в следующий раз столкнувшись с подобным проектом Вы будете меньше и быстрее думать, по-другому будете говорить с заказчиком и он не уйдет.
Совсем без издержек не получится получать заказы.
Что всё таки лучше, чем потом пытаться влезть в сроки, названные от балды. Если заказчик нервничает от того, что Вы сию минуту не можете назвать сроки — что будет, когда вы их начнёте срывать?
Я, как заказчик, заведомо знаю, что сроки будут сорваны. И вношу на это коррективы. В разумных пределах. Такова реальность, увы. Самая смешная тенденция, которую периодически замечаешь — заказчик ставит в качестве условия заведомо невыполнимые сроки, что понятно обеим сторонам. Делается, это, судя по всему, из логики: «Если мы договоримся на месяц, то за два вы точно управитесь. А вот если изначально планировать на два, то не меньше трех реально выйдет...»
А вы как заказчик будете бурно реагировать на срыв сроков, даже если изначально это запланировали?
It depends. В разумных пределах — нет. Если очередной месячный отчет/релиз приходит на пару дней позже — можно считать это техническими проблемами. Если на неделю — повод немного помотать душу. Если месяц — то что-то кардинально не то либо в оценке поставленной задачи либо в производительности труда. Последняя ситуация указывает на проблему с компетентностью как подрядчика/исполнителя, так и, возможно, на мою. Цифры условные и приведены для примера.
Тоесть фактически вы выполняете задачу руководителя.
Конечно, смышлённый заказчик всегда закладывает «подушку» в сроки, ведь всегда могут быть коррективы, даже если проект закончен во время. Но далеко не всегда можно умножить сроки в несколько раз. Тем более, факт значительного срыва сроков обычно указывает на то, что команда не профессиональна, а значит, даже если Вы будете ждать в 2-3 раза дольше — результат всё равно будет печален(Вам ведь его ещё потом развивать/поддерживать). И лучше вот прям сейчас искать других исполнителей.
Конечно, смышлённый заказчик всегда закладывает «подушку» в сроки, ведь всегда могут быть коррективы, даже если проект закончен во время. Но далеко не всегда можно умножить сроки в несколько раз. Тем более, факт значительного срыва сроков обычно указывает на то, что команда не профессиональна, а значит, даже если Вы будете ждать в 2-3 раза дольше — результат всё равно будет печален(Вам ведь его ещё потом развивать/поддерживать). И лучше вот прям сейчас искать других исполнителей.
Поддерживаю!
Лучше назвать предварительные сроки с оговоркой, что более конкретные будут даны после детального анализа проекта. Это подготовит заказчика.
Лучше назвать предварительные сроки с оговоркой, что более конкретные будут даны после детального анализа проекта. Это подготовит заказчика.
Съесть собаку на уникальных дизайнах невозможно. Я, конечно, не говорю о конторах, которые делают говносайты под копирку и говноприложения типа «веселой фермы».
съев собаку на строительстве велосипедовПомедитируйте над этой фразой. Хорошо помедитируйте. Ситуация, которая ею описывается, в применении к софтостроению кажется мне малореальной и дурацкой (если не брать область «сайт на LAMP за полдня и 200 баксов»). «Съедание собаки» должно довольно быстро обернутся изготовлением «фабрики велосипедов», резко удешевляющей изготовление велосипеда.
Это гениально!
Спасибо! Полезно для начинающих РП.
Добавлю, что умножение оценки программиста часто зависит от самого программиста. Оптимисты называют N часов, я прибавляю 70%, пессимисты — M часов, я прибавляю 20%. То есть в зависимости от опыта работы с конкретным человеком или с конкретной командой я всегда прибавляю 20+ % к оценке сроков, тем самым заведомо перекрываю время на напильник.
Многократно при озвучивании даты=оценке заказчику, даже внутреннему, знающему лично исполнителей, приходилось потом отдуваться за задержки. Особенно это касается небольших проектов=доработок, уже завязанных на работающие проекты компании.
Например, если есть рабочая система, а к ней нужно добавить рюшечку, нужно учитывать не только оценку программиста+%запаса, но и отвлечение программиста на чай-кофе-перекуры-другую текучку. Потому что рабочую силу могут выдернуть на что-то более важное для Бизнеса в любой момент. Это проблема любой компании, у которой много мелких, тесно связанных между собой проектов и нет четкого разделения на команды разработчиков в привязке к проектам.
Добавлю, что умножение оценки программиста часто зависит от самого программиста. Оптимисты называют N часов, я прибавляю 70%, пессимисты — M часов, я прибавляю 20%. То есть в зависимости от опыта работы с конкретным человеком или с конкретной командой я всегда прибавляю 20+ % к оценке сроков, тем самым заведомо перекрываю время на напильник.
Многократно при озвучивании даты=оценке заказчику, даже внутреннему, знающему лично исполнителей, приходилось потом отдуваться за задержки. Особенно это касается небольших проектов=доработок, уже завязанных на работающие проекты компании.
Например, если есть рабочая система, а к ней нужно добавить рюшечку, нужно учитывать не только оценку программиста+%запаса, но и отвлечение программиста на чай-кофе-перекуры-другую текучку. Потому что рабочую силу могут выдернуть на что-то более важное для Бизнеса в любой момент. Это проблема любой компании, у которой много мелких, тесно связанных между собой проектов и нет четкого разделения на команды разработчиков в привязке к проектам.
Например, если есть рабочая система, а к ней нужно добавить рюшечку, нужно учитывать не только оценку программиста+%запаса, но и отвлечение программиста на чай-кофе-перекуры-другую текучку. Потому что рабочую силу могут выдернуть на что-то более важное для Бизнеса в любой момент. Это проблема любой компании, у которой много мелких, тесно связанных между собой проектов и нет четкого разделения на команды разработчиков в привязке к проектам.
По-идее все это решается глобальным планом по всем ресурсам. Т.е. вставляя новую задачу с приоритетом, мы двигаем какие-то другие задачи, и эта информация четко доносится до того кто эту задачу пытается пропихнуть. Будь то хоть сам генеральный. Таким образом ответственность за срыв сроков по другим проектам перекладывается с РП на того кто имел полномочия раздвинуть план. И ни в коем случае никогда и никаких неучетных задач, даже «на 5 минут».
Согласна, это прекрасно работает, когда в компании налажен процесс. А когда бардак? Или компания расширилась за полгода с 10 до 100+ человек?
Бардак надо систематизировать и искоренять. То что работало для 10 человек не будет работать для 100. Процесс этот очень тяжелый, и сопряжен с большими рисками. Многие не выдерживают и уходят. Неизбежны регламенты, планы, согласования и прочая бюрократия, иначе все развалится.
В условиях бардака, даже когда топ-менеджмент активно и успешно его искореняет, невозможно на 100% полагаться на ресурсы и давать сроки по формулам.
Не так давно сменив работу, я ушла из перманентного застойного бардака в бардак позитивный, живой и очень этому рада. Я вижу конец этому бардаку. Да, работать мешает, но скоро кончится.
При этом я согласна быть готовой всегда готова к тому, что моего ключевого разработчика уведут на «очень надо, прямо сейчас», а я об этом узнаю поздно.
Как лекарство можно применить ходьбу ногами и многократные уточнения состоянием по ходу разработки/тестирования. Но далеко не все это любят, особенно тимлиды.
Не так давно сменив работу, я ушла из перманентного застойного бардака в бардак позитивный, живой и очень этому рада. Я вижу конец этому бардаку. Да, работать мешает, но скоро кончится.
При этом я согласна быть готовой всегда готова к тому, что моего ключевого разработчика уведут на «очень надо, прямо сейчас», а я об этом узнаю поздно.
Как лекарство можно применить ходьбу ногами и многократные уточнения состоянием по ходу разработки/тестирования. Но далеко не все это любят, особенно тимлиды.
>> невозможно на 100% полагаться на ресурсы и давать сроки по формулам
Можно просто заложить некоторую эластичность в оценки, пропорциональную размеру бардака в компании.
С другой стороны, «позитивный бардак», как вы сказали, неплохо работает в небольших компаниях, имеющих хорошую рыночную нишу и молодой коллектив.
Можно просто заложить некоторую эластичность в оценки, пропорциональную размеру бардака в компании.
С другой стороны, «позитивный бардак», как вы сказали, неплохо работает в небольших компаниях, имеющих хорошую рыночную нишу и молодой коллектив.
Закон Хофштадтера: «Любое дело всегда длится дольше, чем ожидается, даже если при планировании учесть закон Хофштадтера.»
ru.wikipedia.org/wiki/Хофштадтер,_Дуглас
ru.wikipedia.org/wiki/Хофштадтер,_Дуглас
Я не понял проблемы в примере. Велосипед ездит в конце месяца? Ездит. Презентация была? Отлично.
Не вложились. Но полмесяца поработают — допилят. Я считаю, что в примере как раз удачно завершили проект. В полтора раза (а то и два) сроки завалить — это нормально. Практически все удачные проекты минимум во столько раз время превышали.
Бывает, что и за год велосипед не поедет и вообще не поедет никогда. Вот это провал. А в данном случае всё отлично. На моей памяти всегда проекты превышали время, кроме случаев, когда один-два человека разрабатывали и не нужна была сложная координация.
Не вложились. Но полмесяца поработают — допилят. Я считаю, что в примере как раз удачно завершили проект. В полтора раза (а то и два) сроки завалить — это нормально. Практически все удачные проекты минимум во столько раз время превышали.
Бывает, что и за год велосипед не поедет и вообще не поедет никогда. Вот это провал. А в данном случае всё отлично. На моей памяти всегда проекты превышали время, кроме случаев, когда один-два человека разрабатывали и не нужна была сложная координация.
Завал сроков без четкой аргументации даже на неделю без предварительного предупреждения — провал РП.
не будьте идеалисткой. Пацан сказал — пацан сделал — это для бандитов обоснование. А у программистов часто есть объективные причины, которые возникают во время разработки и их нельзя было учесть во время планирования.
Проблема в планировании ИТ процессов имеет глубокую основу.
Планирование вообще возможно только в детерминированном окружении. Т.е. если до начала планирования известно всё и больше ничего не изменится. Т.е. говоря языком математики — больше не будет поступать новой информации. Смешная формулировка для людей, работающих с информацией? А ведь это так.
Поэтому, все руководители и менеджеры, даже возможно не понимая, играют роль эдаких пророков, давая гарантию на то, что может произойти в будущем, когда они не имеют никакого на это влияния или основания.
Лучше всех в том, как быстро разобраться с неожиданно возникшей ситуацией могут только программисты. Значит и проложить путь к наиболее быстрому и лучшему завершению проекта могут только они. Правда, как в статье уместно рассказано, не всегда у них получается планировать взаимодействие.
Изменяться в проекте может всё. Приходить новая информация. Заказчик меняет требования, придумывает новые. Технологии, на которые надеялись от третих стороны (фреймворки, библиотеки) вдруг приносят сюрпризы. Отказываются работать, бывают ошибки, бывает узнаете новое и оказывается, что они не совсем поддерживают то, что нужно именно в этом проекте. И т.д. и т.п. Правильную и быструю реакцию на изменяющуюся ситуацию могут проявлять только программисты.
Поэтому и возникают новые методики, вроде экстремального программирования. На этом фоне руководители — это бараны, пасущие людей. Чаще всего у них задача — выяснять, что думают программисты и далее комуницировать на счет сроков и документации с заказчиком. Что тоже представляется иногда лишним.
Разработка программного обеспечения — один из наиболее рискованных бизнесов. Поэтому можно получать много денег. Но можно и прогореть. Поэтому не тупой заказчик должен вкладывать подушку по срокам и бюджету.
Ругать он, конечно, может за сроки, чтобы не расслаблялись. Но вы должны всё понимать и не деморализироваться — идеальных вещей не бывает.
Далее, чтобы надеяться на программистов — набирайте опытных программистов. Тогда их ругать бессмысленно за проваленные сроки. Хороший, опытный программист, на работе работает и работает хорошо. Если не получилось, значит не могло получиться. У него нет свободного ресурса. Он не играл на рабочем времени в игры. Нерабочее время не учитываем.
Проблема в планировании ИТ процессов имеет глубокую основу.
Планирование вообще возможно только в детерминированном окружении. Т.е. если до начала планирования известно всё и больше ничего не изменится. Т.е. говоря языком математики — больше не будет поступать новой информации. Смешная формулировка для людей, работающих с информацией? А ведь это так.
Поэтому, все руководители и менеджеры, даже возможно не понимая, играют роль эдаких пророков, давая гарантию на то, что может произойти в будущем, когда они не имеют никакого на это влияния или основания.
Лучше всех в том, как быстро разобраться с неожиданно возникшей ситуацией могут только программисты. Значит и проложить путь к наиболее быстрому и лучшему завершению проекта могут только они. Правда, как в статье уместно рассказано, не всегда у них получается планировать взаимодействие.
Изменяться в проекте может всё. Приходить новая информация. Заказчик меняет требования, придумывает новые. Технологии, на которые надеялись от третих стороны (фреймворки, библиотеки) вдруг приносят сюрпризы. Отказываются работать, бывают ошибки, бывает узнаете новое и оказывается, что они не совсем поддерживают то, что нужно именно в этом проекте. И т.д. и т.п. Правильную и быструю реакцию на изменяющуюся ситуацию могут проявлять только программисты.
Поэтому и возникают новые методики, вроде экстремального программирования. На этом фоне руководители — это бараны, пасущие людей. Чаще всего у них задача — выяснять, что думают программисты и далее комуницировать на счет сроков и документации с заказчиком. Что тоже представляется иногда лишним.
Разработка программного обеспечения — один из наиболее рискованных бизнесов. Поэтому можно получать много денег. Но можно и прогореть. Поэтому не тупой заказчик должен вкладывать подушку по срокам и бюджету.
Ругать он, конечно, может за сроки, чтобы не расслаблялись. Но вы должны всё понимать и не деморализироваться — идеальных вещей не бывает.
Далее, чтобы надеяться на программистов — набирайте опытных программистов. Тогда их ругать бессмысленно за проваленные сроки. Хороший, опытный программист, на работе работает и работает хорошо. Если не получилось, значит не могло получиться. У него нет свободного ресурса. Он не играл на рабочем времени в игры. Нерабочее время не учитываем.
Уже который раз сталкиваешься — как бы ни писали ТЗ, все равно оно будет изменено, все равно чего-то не учтешь.
Как бы ни заинтересован был заказчик в результате — с его стороны все равно будут задержки по просмотру/приемке/утверждению/согласованию.
Я для себя уже принял как факт:
1. Оценку программиста надо умножить на 2 и добавить еще чуть-чуть. За 6 лет работы РП — сходится в 95% случаев
2. В ТЗ будут внесены изменения, причем такие, что обосновать дополнительную стоимость будет ОЧЕНЬ сложно, а время на решение задачи увеличится и придется что-то переделывать.
3. Заказчик быстро не реагирует. И надо закладывать в буфер времени (получения оплаты) — некоторую величину, которая тем больше, чем крупнее заказчик.
4. Не добавлять программистов к проекту, когда он уже заканчивается (ну или стремится к этому) — золотое правило еще от Брукса.
5. Для больших проектов — не использовать новые, непроверенные временем инструменты или технологии.
Как бы ни заинтересован был заказчик в результате — с его стороны все равно будут задержки по просмотру/приемке/утверждению/согласованию.
Я для себя уже принял как факт:
1. Оценку программиста надо умножить на 2 и добавить еще чуть-чуть. За 6 лет работы РП — сходится в 95% случаев
2. В ТЗ будут внесены изменения, причем такие, что обосновать дополнительную стоимость будет ОЧЕНЬ сложно, а время на решение задачи увеличится и придется что-то переделывать.
3. Заказчик быстро не реагирует. И надо закладывать в буфер времени (получения оплаты) — некоторую величину, которая тем больше, чем крупнее заказчик.
4. Не добавлять программистов к проекту, когда он уже заканчивается (ну или стремится к этому) — золотое правило еще от Брукса.
5. Для больших проектов — не использовать новые, непроверенные временем инструменты или технологии.
Ну и еще — наличие или отсутствие ТЗ — довольно мало влияет на время разработки.
Есть ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Нет ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Единственное, что иметь ТЗ удобно программисту — как руководство к действию, спокойно почитать и не отвлекать РП
Ну и если закачик хочет фантастическую штуку — можно обосновать что этого в ТЗ не было.
А и еще — бывает что возникает большой пласт работы в конце проекта и необходимо сделать дополнительную фичу, которая в ТЗ не прописана, но всем понятно, что если ее не сделать — проект никому не нужен будет.
Есть ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Нет ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Единственное, что иметь ТЗ удобно программисту — как руководство к действию, спокойно почитать и не отвлекать РП
Ну и если закачик хочет фантастическую штуку — можно обосновать что этого в ТЗ не было.
А и еще — бывает что возникает большой пласт работы в конце проекта и необходимо сделать дополнительную фичу, которая в ТЗ не прописана, но всем понятно, что если ее не сделать — проект никому не нужен будет.
Так в типовой ситуации, как правило, с проектом все-таки справляются. В примере описана проблема отсутствия плана разработки. Если бы он был — через месяц был бы красивый велик в упаковке и без головняков для Васи и его команды.
Конечно ситуация описана идеальная, на практике сильно портят картину нечеткие требования или новые хотелки в процессе реализации, но это выходит за рамки статьи.
PS: Вообще напрашивается целый цикл статей про Васю и его команду. Судя по популярности этой статьи, серию может ожидать оглушительный успех :)
Конечно ситуация описана идеальная, на практике сильно портят картину нечеткие требования или новые хотелки в процессе реализации, но это выходит за рамки статьи.
PS: Вообще напрашивается целый цикл статей про Васю и его команду. Судя по популярности этой статьи, серию может ожидать оглушительный успех :)
Я не считаю, что планирование нужно. Какое-то общение вначале. Лучше, быстро, очень быстро, за пару дней склепать, склеить прототип из бумаги.
Очень хорошо, это попытаться описать и условиться на счет интерфейсов. Т.е. размеры. Интерфейсы, которые нужны только для разделения работ отдельных программистов.
В общем, в статье об этом и говорится, но говорится как о планировании. Да, надо было сразу оговорить, каких размеры и как подойдет к раме колесо или руль. Чтобы распараллелить работу.
А в остальном — аврал — это нормально. Они бы завершили за месяц, если бы описали интерфейсы. Повторю: только те, которые нужны для взаимодействия одного программиста с другим и которые позволят работать с заглушками.
Кстати, замечали когда-нибудь, что если всё распланировать, один хрен почти вся работа делается в последних два дня перед дедлайном. Поэтому режим аврала намного более эффективен. Если научиться им управлять, эффективность разработки возрастет в разы, а то и в десятки раз.
Очень хорошо, это попытаться описать и условиться на счет интерфейсов. Т.е. размеры. Интерфейсы, которые нужны только для разделения работ отдельных программистов.
В общем, в статье об этом и говорится, но говорится как о планировании. Да, надо было сразу оговорить, каких размеры и как подойдет к раме колесо или руль. Чтобы распараллелить работу.
А в остальном — аврал — это нормально. Они бы завершили за месяц, если бы описали интерфейсы. Повторю: только те, которые нужны для взаимодействия одного программиста с другим и которые позволят работать с заглушками.
Кстати, замечали когда-нибудь, что если всё распланировать, один хрен почти вся работа делается в последних два дня перед дедлайном. Поэтому режим аврала намного более эффективен. Если научиться им управлять, эффективность разработки возрастет в разы, а то и в десятки раз.
Многое еще зависит от психотипа ключевых людей в команде. Кому-то комфортно в аврале, кому-то — при четком распараллеливании. Я не сталкивалась с исполнителями, которым нравится аврал. Руководители — да, любят нагнетать.
Знаете, эта статья в многом автобиографична. Я как и Вася долгое время забивал на планирование и закономерно получал ж. Но жить годами в постоянном аврале и факапе сроков стало невыносимо. Поэтому я сел и разобрался где же задница. И результатом стала эта методика. У меня она показала хороший эффект. Но это конечно не серебряная пуля, небольшое подспорье в работе РП.
Конечно, статья хорошая и смысл в ней есть. Только, имхо, не надо впадать в другую крайность — в водопад.
Распараллелить работу — вполне нужно. Но и помнить, что траектория снаряда всё время меняется и надо по возможности чаще общаться и корректировать планы.
А работа в режиме аврала, если привыкнуть, совсем не изматывает. Это просто работа, почти под сто эффективности, немного меньше. От звонка до звонка. Не по ночам и не по выходным. Умение программистов быстро комуницировать между собой, принимать решения и не полагаться на какой-то план. План для программиста — это всего лишь способ урвать свободное время. Завершил на пару часов раньше задачу, можно ничего не делать. А это негативно влияет на производительность. Любое отвлечение от работы, потом тяжело снова начинать. И так работать — еще больше изматывает. Наиболее тяжелая работа для программиста — это когда нет работы.
Вот я сейчас каменты пишу, потому что по планам задачу выполнил, которую должен сдать в понедельник )))
Правда, сейчас придумаю себе задачу и перестану писать ))
Распараллелить работу — вполне нужно. Но и помнить, что траектория снаряда всё время меняется и надо по возможности чаще общаться и корректировать планы.
А работа в режиме аврала, если привыкнуть, совсем не изматывает. Это просто работа, почти под сто эффективности, немного меньше. От звонка до звонка. Не по ночам и не по выходным. Умение программистов быстро комуницировать между собой, принимать решения и не полагаться на какой-то план. План для программиста — это всего лишь способ урвать свободное время. Завершил на пару часов раньше задачу, можно ничего не делать. А это негативно влияет на производительность. Любое отвлечение от работы, потом тяжело снова начинать. И так работать — еще больше изматывает. Наиболее тяжелая работа для программиста — это когда нет работы.
Вот я сейчас каменты пишу, потому что по планам задачу выполнил, которую должен сдать в понедельник )))
Правда, сейчас придумаю себе задачу и перестану писать ))
>> Умение программистов быстро комуницировать между собой, принимать решения и не полагаться на какой-то план
Это умение опытных программистов, потенциальных тимлидов и РП. Еще и очень хорошо промотивированных на творческий подход. К сожалению таких немного и стоят они дорого. Обычной боевой единице нужна четкая задача, достаточно вводных данных и готовая инфраструктура для решения этой задачи.
А то что план может меняться на лету — совершенно справедливо. Но надо же с чего-то начинать.
Это умение опытных программистов, потенциальных тимлидов и РП. Еще и очень хорошо промотивированных на творческий подход. К сожалению таких немного и стоят они дорого. Обычной боевой единице нужна четкая задача, достаточно вводных данных и готовая инфраструктура для решения этой задачи.
А то что план может меняться на лету — совершенно справедливо. Но надо же с чего-то начинать.
Смотря что звать «планом» — сетчатый график или детальную разблюдовку по часам.
Это стоило бы почитать конструкторам суперджета
Спасибо от начинающего руководителя! =)
Хорошо показано, что с ростом команды для обеспечения распараллеливания возникает необходимость в доп. работе — в частности, по предварительной разработке интерфейсов.
Интерфейс всегда продумывается предварительно! Иначе будет ну ни разу не юзер френдли :)
Проект интерфейса должен существовать да начала разработки.
Вообще-то в статье я говорил об API, не о GUI. На счет GUI не все так однозначно, в какой момент его начинать делать.
Согласна, неоднозначно.
Но все же при проектировании архитектуры будущего продукта стоит уделить время основным элементам пользовательского интерфейса.
Чтобы не получился велосипед, который быстро едет, управляем, но элементы управления неудобны или неочевидны.
Согласитесь, переключать скорости руками под сиденьем неудобно :)
Если сразу заложить элементы управления=использования с учетом сценариев использования, то продукт будет удобен и неперегружен лишними настройками.
Очень печально использовать программные продукты и испытывать недовольство от кучи излишних параметров и необходимости делать 8 кликов для 1 простого и постоянно повторяемого действия.
Это я и понимаю под проектированием интерфейса одновременно с элементами системы.
А когда продукт разрастается без плана, почти всегда на выходе получаются перегруженные интерфейсы и недовольные пользователи.
А что касается API, то это тоже интерфейс. но для разработчика. И он тоже должен быть продуманным и удобным, а так же проектироваться на стадии общего проектирования. Добавлять в наспех придуманный API новые функции нехорошо.
Но все же при проектировании архитектуры будущего продукта стоит уделить время основным элементам пользовательского интерфейса.
Чтобы не получился велосипед, который быстро едет, управляем, но элементы управления неудобны или неочевидны.
Согласитесь, переключать скорости руками под сиденьем неудобно :)
Если сразу заложить элементы управления=использования с учетом сценариев использования, то продукт будет удобен и неперегружен лишними настройками.
Очень печально использовать программные продукты и испытывать недовольство от кучи излишних параметров и необходимости делать 8 кликов для 1 простого и постоянно повторяемого действия.
Это я и понимаю под проектированием интерфейса одновременно с элементами системы.
А когда продукт разрастается без плана, почти всегда на выходе получаются перегруженные интерфейсы и недовольные пользователи.
А что касается API, то это тоже интерфейс. но для разработчика. И он тоже должен быть продуманным и удобным, а так же проектироваться на стадии общего проектирования. Добавлять в наспех придуманный API новые функции нехорошо.
Все это прекрасно и верно, но только в случае фиксированных и неизменных требований заказчика. А такого в моей практике не случалось, к сожалению :)
Но ведь можно зафиксировать требования хотя бы на первую итерацию/билд?
А потом уже править методом комплексного добавления/удаления опций :)
Всегда можно найти компромисс, если очень захотеть.
В моей практике. к сожалению, было мало продуктов, для которых требования бы не менялись вообще. Но все же такие случаи были и это великолепно сказалось на конечном продукте.
А потом уже править методом комплексного добавления/удаления опций :)
Всегда можно найти компромисс, если очень захотеть.
В моей практике. к сожалению, было мало продуктов, для которых требования бы не менялись вообще. Но все же такие случаи были и это великолепно сказалось на конечном продукте.
Если мы говорим об интерфейсах программных продуктов (не важно, веб., десктоп или клиент-сервер), то нужно думать не только о функционале и архитектуре, но и о сценариях использования.
Программист, разрабатывающий на основе API продукта, в определенном роде тоже пользователь и его потребности нужно учитывать.
При этом кнопочки и их местоположение не входят в это проектирование, они будут сделаны потом.
Недаром есть специально обученные люди, привлекаемые для проработки пользовательских сценариев еще на стадии проектирования.
А еще фокус-группы из потенциальных пользователей, благодаря которым можно учесть и исправить замечания и неудобности…
Проблема в том, что понимание необходимости этих действий есть далеко не у всех руководителей и далеко не на всех проектах.
Программист, разрабатывающий на основе API продукта, в определенном роде тоже пользователь и его потребности нужно учитывать.
При этом кнопочки и их местоположение не входят в это проектирование, они будут сделаны потом.
Недаром есть специально обученные люди, привлекаемые для проработки пользовательских сценариев еще на стадии проектирования.
А еще фокус-группы из потенциальных пользователей, благодаря которым можно учесть и исправить замечания и неудобности…
Проблема в том, что понимание необходимости этих действий есть далеко не у всех руководителей и далеко не на всех проектах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мы сделаем этот велосипед за месяц