А что думает ТС про книжку «Как пасти котов»?

Присоединяюсь, хорошая книга.

Глянь авторов: Кент Бек, Мартин Фаулер.

отличная книжка.

к сожалению, к сабжу (оценке efforts) не относится никак

они говорят, что сначала нужно тестами обмазаться с ног до головы, но не говорят сколько это стоит :)

брукс слишком сферичен?

оцениваешь трудозатраты, потом умножаешь на 3, потом ещё раз на 3 - и может быть в этот срок уложишься :)

мифический человеко-месяц - это любимая книга. Нужны другие акценты. Вот тебе приехал новый проект, кое-как согласовали фичи. И теперь нужно ответить, сколько это займет времени, сколько будет стоить, какая модель разработки, какие этапы, выдать чиселки по всем этим этапам. Рутина PM-аналитика. Вот с конкретными приемами этого всего, для конкретной области (н-р «разработка на аутсорсной фабрике») и хотелось бы познакомиться.

Я сейчас ботаню материалы Стратоплана, но оно пока всё про другое, про хуман-специфичное. Это всё тоже важно и нужно, но и аналитика важна.

пробиваешься в эффективные менеджеры? :)

если у самого опыта ноль, найми себе тимлида, которому ты веришь.

стандарт ISO 9126

он в общем, рамочно показывает — какие критерии, как оценивать. далее, если ты про «проект» в смысле продукт, то есть результат проекта — то это он. если ты про «проект» в смысле управления проектами и процессами управления проекта — см. другие стандарты ISO (ISO 12207 , и PMBOK например.

ещё глянь про критерии CMM, уровни зрелости (level 1 .. level 5) оттудова, и соответственно, PSP/TSP.

ещё читай например про фабрику программ, алгебру алгоритмов

вот, кстати, хороший учебник по software engineering: книга — здесь тебя интересуют в основном, модель качества ПО и модель управления проектом разработки ПО

также полезно почитать книжку А. Левенчука, например, про системную инженерию

он хорошо, много и весьма годно пишет на эту тему в своём блоге (вот например, краткое введение, ещё здесь, здесь и здесь)

практически весь его блог весьма годен, рекомендую. он пишет о системной инженерии в целом, без особого акцента на софтверную инженерию.

а вообще критерий оценки простой — взлетает или не взлетает. все остальные критерии — муть полная. "- почему не стреляли пушки? - существует 12 причин. - во-первых, не было пороха.. - можете не продолжать".

здесь упор должен быть не на то, что и крокодилы летают, только низенько. а на то, как надобно правильно процесс поставить.

Оно, не?

Джоэль Сполски и метод освоенного объёма

и вот здесь

и вот здесь ещё кратко пишет для введения в предмет (сориентировать, куда тебе надо)

Хз как тебе удаётся уболтать клиента раскошелиться на запрашиваемую сумму.

Привет. Откуда дровишки, ты манагер?

Rational Unified Process, планирование в UML, и тем более Rational Rose и прочую фигню никто уже не использует, ее выкинули тысячу лет назад. Это не работает.

Про CMM непонятно. Ну да, это какая-то методика для заказчика оценить, как мы работаем. Даже опустим то, что имхо CMM 5 скорей всего означает загнивающий аутсорс, клепающий однообразное говно, а мне хочется что-то ближе к R&D. Основной вопрос тут, как мне CMM поможет в оценке efforts?

Про Левенчука тоже непонятно. Его «системная инженерия», вроде бы, - это сложная вундервафля, основанная на его технологиях. В основом, какая-то заоблачная теория, отражающая его понимание предмета, которое (понимание) меняется раз в год. Как мне это поможет вот прямо сейчас?

Хочу повторить/упереть на кейс. Приходит заказчик и хочет, чтобы мы разработали ему банковскую систему на Java. Или какой-то сложный сайт с сотней всяких хитрых кастомных фич. Это такая обычная типовая вещь, которой у нас занимается половина города. Хочется получить какой-то курс молодого бойца, чтобы хотя бы не обосраться на собеседованиях. Я понимаю как это происходит, но больше с точки зрения девелопера. Например, совершенно непонятно, как _быстро_и_просто_ расчитывать Очень Большие Риски.

быстро и просто оценивать очень большие риски

😊

Нам нужна банковская система. Сколько это будет стоить и займет? А вы им в ответ по формуле посчитав - год времени и миллион зелени. Они - да без проблем, вот миллион зелени. А вы им так через год приносите банковскую систему. Они в восторге, вы рады, все счастливы. Хороша формУла!

А вот элементарный вопрос - как вы вообще можете гарантировать, что сможете разработать банковскую систему в соответствии с требованиями?

А вот элементарный вопрос - как вы вообще можете гарантировать, что сможете разработать банковскую систему в соответствии с требованиями?

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

А вообще нет, не правильно я сказал, есть верное средство - наймите опытного человека. Совет же тебе - стать этим опытным человеком. Займись управлением разработкой с небольшой команды и небольших проектов. И сам по цене и срокам не принимай решений до тех пор, пока этим опытным человеком не станешь.

а чтобы получить небольшую команду, нужно как минимум пройти собеседование и устроиться манагером. А чтобы сделать это, нужна информация, о которой я здесь, черт возьми, и спрашиваю.

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

Приходит заказчик и хочет, чтобы мы разработали ему банковскую систему на Java

Вот в этом месте проиграл.

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

я рабоаю в стартапе из 3,5 человек, тут не нужны менеджеры вообще

ты хочешь чтобы я тебя пожалел?

почему бы не пойти в контору покрупнее на аналогичную позицию? набраться практического опыта в интересующих тебя типах проектов?

нет, не хочу. Я хочу конкретную информацию. Ссылки на исследования по методам оценки, тексты докладов по теме, современных учебников по менеджменту в IT, итп.

оценка в чем, в часах работы?

тут только опыт и перестрахование себя помогут, в книжках тебе такие точные специфики никто не изложит.

сам этим регулярно занимаюсь в течении многих лет, примерно представляет такой процесс..

на первой встрече с потенциальным клиентом обычно не бываю, там собирают брифинг и первичное интервью, все дела

далее уже обращаюсь ко мне с вопросом «скока часов это займет», смотрю ту инфу что есть от клиента, если у него нихрена нет (или тухлое призрачное тз), но выяснили что клиент при бабле и готов платить то иду на вторую встречу, где задаю over 9000 деликатных вопросов что бы прояснить технические требования в общем и целом, потихоньку складывается картина в голове, беру таймаут на некое время, что бы проработать это в фоновом режиме, ищу острые моменты реализации которые могут убить весь проект в перспективе, проясняю их в виде доп. общения с клиентом или просто по почте, четкого тз на данный момент еще нет, для этого клиент должен начать платить.

далее соответственно раскладываю это примерно по модулям реализации и оцениваю их в часах, если есть всякие API сервисов о которых я не знаю, смотрю документацию, если нет документации и это интегрированная система заказчика, то общаюсь с человеком который ее реализует с их стороны, узнаю протоколы и data flow в данной системе, потом еще раз оценочно на все это дело смотрю и оставляю такую же оценку либо накидываю еще часы, так же накидываю часы в % соотношении на возможные правки/уточнения/провисоны (тут где-то 20% обычно) и выкатываю оценку

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

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

нужно как минимум пройти собеседование и устроиться манагером

решил закончить с разработкой?

нет, не хочу. Я хочу конкретную информацию. Ссылки на исследования по методам оценки, тексты докладов по теме, современных учебников по менеджменту в IT, итп.

Я тебя сейчас расстрою, но основной багаж манагера - это как раз опыт, умение находить компромисы и наработанные деловые контакты (это тоже ресурс).

Из буквоедов хороших манагеров не выходит. Весь ITIL тому подтверждение (но далеко не для всех очевидное).

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

давай я «дам» тебе на аутсорс маленький кусочек проекта: «реализовать аутентификацию пользователей согласно требованиям фстэк». оценивай!

традиционный вопрос - ты маангер/лид?

Из буквоедов хороших манагеров не выходит.

почему-то в половине книжек манагеры пишут, что второй по важности навык для самообразования - непрерывное чтение.

в миг перечеркнет

Факапы можно классифицировать, скоррелировать с типом работ, не? Например, Вася в предыдущих 10 проектах факапил 10% задач, и все задачи типа «верстка» делал в 2 раза медленней, чем задачи типа «программирование». Потом взять work breakdown structure, классифицировать по типам работ, те работы типа «верстка» которые некому делать отдать Васе с понижением вероятности(ожидания завершения) итп. Это то, что это «само собой разумеется» на моем уровне, но пока не узнаешь - оно из ниоткуда не возьмется, там наверняка еще куча таких очевидностей, составляющих работу оценщика

сделать это можно разными способами. У нас в предыдущих компаниях были Регламенты, в которых были кровью и болью полученные «истинно верные» решения. Кое-каких манагеров вообще просто уволили и заменили на Регламенты xD Но я программист, поэтому у меня доступ был только к программистской части знания: например, релизить надо вот с такими таймингами, которые связаны с вот такими бизнес-процессами, и если тайминги покорраптить, то роллинг-релиз превратится в роллинг-хаос, и вот почему.

В первую очередь хотелось бы почитать вот такие вещи, «схемы бизнеса», внутренние ритмы.

в миг перечеркнет

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

ну не совсем с разработкой, иначе можно деградировать до управления ларьком с сосисками или строительства собачьей конуры. Хочется переквалифицироваться в ПМа софтварного проекта.

но есть проблема. Я какбы последние лет 8 жил фрилансером. Чтобы «обычным способом» добраться до руководства, надо устроиться джуниором-программистом в какую-нибудь бюрократическую контору, пишущую на Java/.NET, и потом потратить еще лет 5 чтобы добраться до архитектора, и потом (с огромным просиранием скилла) переквалифицироваться в ПМы. Куча лет такой короткой жизни, которые будут просраны зазря. Куча бесполезной информации технического плана, которые будут изучены только затем, чтобы быть выброшенными. Русский кодинг - абсолютно бессмысленный и беспощадный. Это очень ужасает :(

но так, наверное, и придется сделать. А пока поброжу по собеседованиям, может меня кто возьмет третьим заместителем с конца младшего джуниор-ПМа.

то есть, ты сам оцениваешь время, не спрашиваешь у разработчика, и потом ставишь ему дедлайн? Или разработчик - это ты?

Или разработчик - это ты?

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

А пока поброжу по собеседованиям, может меня кто возьмет третьим заместителем с конца младшего джуниор-ПМа.

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

что бы проработать это в фоновом режиме, ищу острые моменты реализации которые могут убить весь проект в перспективе

забавно, что обычно поступают наоброт - все такие острые откладывает на самый конец. Ну и потом самый конец работы превращается в кошмар, т.к. в кратчайшее время надо пройтись по всем граблям сразу :) Я вот как разработчик люто ненавижу такой оптимистичный подход. Особенно когда его диктует заказчик (я заказчик, и я вам говорю что вот это мы будем прикручивать на последней итерации!)

дык может пойти туда, где твои навыки объективно оценят как джуниорские?

а то ведь устроишься пм-ом в рога и копыта и будешь там пилить хелло-ворлды и выносить мозг ни в чём не повинной молодёжи своими извращёнными фантазиями на тему того как правильно.

я заказчик, и я вам говорю

если бы ты был толковым пм-ом, то на этом основании аргументированно перевесил бы на него риски. такие хорошие заказчики на дороге не валяются :)

Ну и потом самый конец работы превращается в кошмар

проблема в том, что ты возьмешь такого клиента на 1 раз т.к. нервотрепка будет адская в итоге если на все это забить, надо сразу все эти углы обходить и тогда получится долгосрочное и выгодное партнерство (сдавать в сроки проекты надо, да)

кто остальные три человека?

ты видел где-нибудь в глубинке вакансию «джуниор-ПМ»? Москва - да, США - да, а по Роиссе считается, что якобы манагер - это «начальник», царь и бог. Какой-то элемент рабской психологии, доставшейся со времен крепостных крестьян, наверное xD

Мне больше нравится понимание ПМа как обычного сотрудника, который выполняет особый класс задач вместе с выделенным аналитиком, архитектором, сеньер-девелопером. Заодним подчищает за всеми некомпетентность (девелопер, который не умеет связать два слова, архитектор кроющий лигаси-код матом), и вывозит то, чем другие заниматься не хотят (начиная с жалкими отмазками перед бизнесом, и заканчивая «принести всем на рабочее место кофе, сами не принесут»).

Т.е. это скорей работа ассенизатора, а не бога. К сожалению, при оглашении такой позиции на собеседовании на тебя смотрят еще более квадратными глазами, и посылают нахрен быстрее xD

традиционный вопрос - ты маангер/лид?

рук.подразделения

второй по важности навык для самообразования - непрерывное чтение.

«Непрерывное чтение» - это всё-таки не навык, а скорее процесс. Вот умение читать и анализировать прочитанное - это уже ближе к навыку. Да и сама формулировка, честно говоря, не фонтан. Но это не суть. Если не вдаваться в детали, то чтение - это получение теоретических знаний (это даже навыками по сути назвать нельзя). А любая теория должна быть закреплена практикой. И только опробовав на практике идеи и мысли коллег по цеху можно понять о приемлимости их для тебя. Как в плане уже выстроенного процесса, так и в моральном аспекте. Можно еще кстати каснуться сугубо физиологических особенностей человека - неиспользуемые знания имеют обыкновение улетучиваться из головы.

Факапы можно классифицировать, скоррелировать с типом работ, не?

Это уже «риск-менеджмент». И это одна из важнейших проблем в оценке и планировании. К сожалению, невозможно заложить все форс-мажоры в проекте. Даже будучи уверенных в том, что твои Сотрудники не будут лениться и никто не уволится до завершения проекта (мы же платим 150% от рынка, куда они убегут!) - в самый неподходящий момент из команды вылетит... пускай не сеньор или не дай бог архитектор, но какой-нибудь тимлид неожиданно склеит ласты. В рамках выбивания пролонгации сроков куда выгоднее спалить весь офис дотла, чем пытаться объяснить задержку подобной hr-проблемой (к сожалению, это не минутка черного юмора, а такие заказчики-муд...ки реально существуют).

У нас в предыдущих компаниях были Регламенты, в которых были кровью и болью полученные «истинно верные» решения.

Вот это, кстати, в тему ITIL-подобного. Важно понимать один концептуальный момент. Если ты манагер - ты эти регламенты пишешь Но ты их при этом не обязан соблюдать! Менеджер должен быть гибким и мобильным, принимать решения исходя из конкретной сложившейся ситуации. Часто выгоднее отойти от правил и решить проблему иным способом. Но подобное можно доверять только людям, которые несут ответственность за результат. Исполнители на местах должны или действовать по правилам, или же оперативно эскалировать проблему до человека, который и может решать проблему иначе (кстати, этот вариант развития тоже надо налаживать).

всё равно бизнесу нужно выдать бизнес-план.

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

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

Т.е. это скорей работа ассенизатора, а не бога.

дык какого ты тогда тянешь на себя ещё и одеяло пре-сейла?

Даже сами кодеры часто ошибаются. Раза так в 2. Чего ты хочешь?

а такие заказчики-муд...ки реально существуют

а у них в договоре прописано, что они разделяют твои хр-риски? :)

они, скорее всего, подписывали договор с надёжным партнёром, имеющим огромный опыт как в разработке по вообще, так и в предметной области в частности :)

А любая теория должна быть закреплена практикой. И только опробовав на практике идеи и мысли коллег по цеху можно понять о приемлимости их для тебя.

большая проблема в том, что 90% авторов книжек - бездельники, лгуны и шизофреники. Бессистемно внедрять всё, на что упал взгляд - так же можно с катушек съехать, не? И окружающие будут смотреть на твои «внедрения» странно - капец, опять у чувака крыша едет, все в машину :-)

Вот это, кстати, в тему ITIL-подобного.

хорошо, подробней погляжу про ITIL

Для «бизнес-плана», выражаясь твоим определением :)

Про надевание неудобного доспеха: «всё зависит от того, что больше делаешь - срёшь или сражаешься». С бизнес-планом ходят к инвесторам, чтобы получить от ворот поворот :)

Порекомендую тебе примерно следующее:

(Общая картина) Для начала почитай о том, как это вообще бывает. Какую-нибудь беллетристику, типа Тимоти Листера и Тома Де Марко. Чтоб получить общее представление. Ты говоришь читал Брукса? Почитай ещё что-нибудь.

(Составные части) Потом почитай любую не очень большую книгу, название которой содержит слова software project management. Если тебе кажется, что там написана фигня, что ты и так дока в этом деле, что ничего нового ты не узнаешь - все равно читай.

(Примеры) Потом почитай про какие-нибудь современные методологии управления разработкой программ - итеративные там, адаптивные например.

(Детально) Каждый процесс, про который можно сказать, что он является частью управления разработкой ПО, изучить придётся намного глубже. Ты должен все знать о процессе - не в разрезе какой-то конкретной методологии, а в целом.

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

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

Ну, то есть, когда говорят что «менеджер всегда должен читать» именно это и имеют ввиду, я думаю😊

Как видишь, это очень далеко все от ответа на вопрос «сколько это будет стоить и сколько времени займет», кроме разве что совсем простых случаев.

ещё книжка про agile: гибкие методологии разработки. вольфсон борис

оттуда смотри процесс планирования релизов: планирование спринта в SCRUM, planning poker и т.п.