Начну издалека. Представим себе, что мы находимся в командовании штаба армии. На столе разложены карты и идет совещание, как направить фронты и какой длительности должна быть операция. Когда проводят стрелки как направить армию, то обычно смотрят, чтобы оно не проходили через болота. Есть конечно некоторое количество Суворовых, ведущих войска через Альпы, но даже они не рассчитывают, что скорость передвижения будет такая же как по равнине. Ну, и если на карте есть белые места, то сначала посылают разведку поглядеть, какая там местность, а уж потом пускают войска.
Теперь вернемся к глупым IT’шникам (особенно это относится к менеджерам). У нас есть проект и его положение мы видим на карте, есть точка, куда мы хотим передвинуть этот проект. Менеджер (хотя это может быть и программист или тестировщих) рисует прямую между этими двумя точками и говорит: «Господи, да тут и делать нечего. Расстояние всего-то три шага». Проблема заключается в том, что ни болота, ни горы на карте, которую все пользуют не нанесены (так как территория не изведана). И получается, что расстояние то три шага, но между двумя точками может быть непреодолимая бетонная стена двадцати метров высотой и длинной десять километров.
Посему, перед тем как делать любые выводы сколько там шагов займет добраться от точки А до точки B, либо найдите человека, которых ходил этим путем (или по крайней мере похожим), либо проведите разведку (прототипирование), либо почитайте, о том, сколько войск погибло при переходе через Альпы (даже у успешного Суворова).
Собственно говоря, меня просто бесит, когда активный менеджер, бросает «войска» в бой с целью за три дня добраться до места, при этом не зная поля боя. Я чаще всего в таком случае машу ручкой и говорю – удачи вам товарищи, а я тут ногу подвернул, так что потихоньку сзади вас прихрамывая дошагаю (сам в это время проводя разведку местности). Ну и чаще всего мой прихрамывательный шаг по лесной окружной тропинке, оказывается гораздо эффективнее, чем наскок кавалерии на 20-и метровую стену.
Вот такая вот мысля.
Эх… А ведь были времена, я сам на коне, с шашкой на голо — пытался пробить стену головой 🙂 Молодость…молодость 😉
И как голова сейчас себя чувствует ? 🙂
Мне кажется это не только проблема IT. Для нас это наболело просто.
Это проблема неопытного человека. В любой отрасли.
— Девелопер накодид неоптимально.
— Тестировщик протестирует не то или не все.
— Суппорт человек не поймет проблему и зачитает не тот абазац из каких-то справочников
— Продавец продаст клиенту одно, скажет исполнителям другое и сделает ошибку в конечной цене
— Руководитель неверно оценит очередные показатели бизнеса, и уведет команду в задницу
— Политик просто в какой-то экстремальный момент ляпнет что-то лишнее на интервью, на которое в принципе мог и забить
Семь раз отмерь как говорится 🙂
>И как голова сейчас себя чувствует ? 🙂
Та ничего… за давностью лет уже прошла 🙂
Да, я согласен, что не только проблема в IT. Просто IT настолько стремительно (по сравнению с другими областями) несется вперед, что фактически постоянно идет конная атака неизведанных областей.
Например в автомобилестроение вряд ли каждый 5 лет появляется что-то супер новое насчет того, как делать мотор. Больше того, обычно если появляется, то разрабатывают это люди, которые уже лет 20 моторами занимались, и прототипирует и гоняют лет 5, а только уж потом ставят на производство.
Я не слишком знаком с другими отраслями, но думаю достаточно мало есть таких где количество заваленных проектов, и проектов которые вышли в 3 раза дороже и дольше чем расcчитывали — больше чем в IT
Хорошие, не побоюсь этого слова, аллегории. (и не только в этом посте).
Так держать! 🙂
🙂 Спасибо на добром слове 🙂
Если планирование идет на уровне безграмотности этой фразы:
«Представим себе, что мы находимся в командовании штаба армии. На столе разложены карты и идет совещание, как направить фронты и какой длительности должна быть операция. Когда проводят стрелки как направить армию, то обычно смотрят, чтобы оно не проходили через болота.» — всуе использованы термины «фронт», «армия», «операция», словосочетание «командование штаба армии», — результаты будут сугубо предсказуемые.
Сначала анекдот:
«Умерли водитель и священник. Водителя Господь отправил в рай, а священника — в ад.- Помилуй, Боже, за что?! — изумился священник.- На твоих проповедях прихожане спали, вместо того, чтобы молиться. А в его автобусе они молились, вместо того, чтобы спать…»
А теперь ответ, на ваш комментарий.
Можно говорить/писать правильные слова с орфографической, стилистической и других точек зрения и при этом никому не будет интересно. А можно и безграмотной фразой вызвать интерес.
P.S. Термины “фронт”, “армия”, “операция” не являются именами Бога и их вполне можно употреблять всуе.
«На твоих проповедях прихожане спали, вместо того, чтобы молиться. А в его автобусе они молились, вместо того, чтобы спать…”
Полагал сей сорт деятельности в Инете эксклюзивом порнушников и пАдонков, в противоположность «глупым ИТ’шникам».
Не совсем понял, что подразумевается под словом «сей»?
Я говорил о том, что моя цель, чтобы меня интересно было читать. Моей целью не стоит написание докторской диссертации (в которой каждый термин, должен стоять на своем месте).
Да уж ойтишнеги не то что тупые просто глупые и наивные.
О да! Беда в другом: прототипирование или поиск специалиста, решавшего подобную задачу — это затраты. Которые малая компания позволить себе не может (у клиента горит, небольшой бюджет, полно таких проектов на дню, что за каздым бегать и проводить ресерч — себе дороже), а большая… не знаю, в больших не работал, подозреваю, что все утонет в бюрократии.
Однако идеи верные, согласен всеми руками.
Да, естественно — прототипирование или специалист — дополнительные затраты. Чаще всего они в результате окупаются.
Я тут недавно начал на горных лыжах кататься. Приведу пример из них, подъезжаешь к крутому склону — страшно. Начинаешь ехать — оказывается не такая большая проблема и вовсе и не страшно.
Тоже самое с прототипирование или специалистом. Делать их страшно, так как дополнительные затраты, но когда уже процесс пошел, то все оказывается не так плохо как предполагалось.
Я просто помню, как мы нанимали первого программиста, и тряслись поставить ему чуть больше денег, так как у нас тогда очень немного финансов было. В результате наняли более молодых специалистов, хотя как сейчас понимаю, имеет смысл нанимать наилучшего до которого можно дотянуться.
Да кстати, бюрократия действительно страшная вещь. И самые лучше начинания тонут в ней как в болоте.
Очень интересно!
Я думаю, это скорее вопрос культуры и воспитания, чем недостатка квалификации. Воспитанный человек всегда вначале выслушает до конца все точки зрения, а потом начнет делать выводы. Культурный же человек — не будет спешить, перебивать других, относиться с презрением к опыту поколений и традициям.
При соединении этих двух качеств даже низкоквалифицированный исполнитель не будет «ломиться сквозь стену». Просто потому, что учтет не только свое «единственно правильное» мнение.
Этот пост некисло кстати пересекается с постами про эстимейты и про «синхофазотрон». Дело в том, что дать толковый эстимейт приближенный к реальности можно только на ту задачу которую ты уже делал. При чем если ты задачу уже решал, то вероятнее всего она была для тебя тогда новой и щас ты ее уже сделаешь быстрее. А если это касается кода и ты достаточно умен, чтобы писать код свой заранее затачивая его для реюза и хранишь его потом, то для решения таска вообще практически не потребуется времени, только лишь небольшой рефакторинг может быть. Ну или второй вариант — это когда твой старый код тебе уже не принадлежит и тебе нужно писать его снова, или же писать на другом языке (только вот в этом случае кодер будет не достаточно мотивирован. Делать то, что ты уже когда то делал — всегда скучно.). Потому в подавляющем большинстве случаев кодер или менеджер оценивает таск новый для себя. И это нормально. Так и должно быть.
Кстати, еще один момент. Считаю, что держать аналитика, который будет оценивать таски для других, более слабых и менее опытных кодеров — это не правильное решение, т.к. этот опытный кодер вряд ли вообще знает для кого он делает оценку. Но в принципе я думаю, если такому опытному аналитику давать почитать код человека, который будет решать таск, написанный кодером за последние две недели, то может получиться вобщем то что то похожее на истину. Это правда только моя идея, которую стоило бы проверить на практике.
Да, у меня вообще много постов пересекается с синхрофазотроном. Я бы сказал, что это одна из моих любимых тем — эффективность.
Просто, как-то обидно выходит, когда микроскопами забивают гвозди, а молотками пытаются вышивать гладью.
Да, я согласен, что в большинстве случае, оценивается таск новый для себя и именно поэтому нужно либо считать риски и их добавлять, либо создавать прототип.
Насчет аналитика. Не знаю, у меня тут смешанное отношение. С одной стороны, да действительно хорошо, чтобы аналитик делал estimate. С другой стороны, даже глядя на чей-то код, тяжело правильно оценить коэффициент, на который надо домножить.
В свое время, я достаточно долго был аналитиком и если честно, то я был не слишком рад, тому, чтобы оценивать сколько задача займет у другого человека.