![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
towndwarfhttp://www.silicontaiga.com/articles/000013.html
Менеджмент проектов для падонков: оценка временных затрат
Эх, давно не брал я в руки шашку, но, похоже, труба зовёт. Спасибо неизвестному Роману, возвашему к мачо с просьбой поделится методиками оценки временных затрат на проект, на что мачо со свойственным им понтом нахуярили кучу умных слов, из которых мне известна лишь пара, а именно заточенные и конкретно... Самое время вспомнить добрым словом господина Maxel, предложившего отличать мачо от переученного чмо.
Не хочется никого в чём то убеждать, реальные перцы и так знают единственный метод оценки временных затрат, который имеет лишь разные названия в различных субкультурах и слоях IT сообщества. Господин Йордон (Yourdon) называет этот метод колдовством или магией, лично я спрашиваю ответа у своей жопы, а кто-то жабу лижет дабы просветиться, но в любом случае суть одна и та же. Нет таких методов, и как не выёбываться - жопа (или жаба) будут точнее.
Игорь Скляр точно подметил, что базовый принцип оценки временных затрат универсален, поэтому я позволю себе утверждать что технология оценки временных затрат на съём бабы на ночь и на выполнение некоторой части проекта одна и та-же. Серьёзный проект сопоставим с задачей вида: совершить сотню половых актов, причём некоторые из них - с вполне определёнными бабами, зачастую страшными, или замужем за ахуенно ревнивыми штангистами, а некоторые в особо извращённой форме.
Таким образом не зная ответа на элементарный вопрос - сколько времени потребуется на то, что бы снять и поиметь женщину, вообще нехуй браться за оценку временных затрат на проект. Опытный же девелупер знает, что с вероятностью, например 25%, он находит подходящую кандидатуру в пятницу - субботу вечером, с соответствующим актом удовлетворения в воскресенье, ну или на следующей недели. Таким образом можно сделать оценку производительности данного девелупера в 12 баб в год (ну 10 с учётом авралов на основной работе).
Безусловно 10 баб в год есть херовая производительность и тратить 100 человеко-лет на проект в 1000 половых актов как-то совсем невесело. Поэтому нас страшно интересуют технологии, позволяющие ускорить процессы создания программных проектов.
А вот теперь мы вплотную подходим к реальным муткам, которые, не меняют технологии оценки временных затрат, но позволяют указать на некоторые тонкости как программных так и других проектов в целом.
Технологии эти общеизвестные, но как я заметил, любой менеджмент в силу отсутствия образования и/или понимания, на них не обращает внимания, продолжая тупо делить проект на мелкие задачи, и получая в результате 100 человеко-лет и причмокивания органом.
Переиспользование (reusing): позволю себе процитировать по памяти Синклера, который как-то давно в летней кафешке перед "Городком" сказал мне примерно следующее: сложность задачи не уменьшается... мы можем лишь ускорить процесс благодаря реюзингу, а наследование и полиморфизм - наиболее мощные способы реюзинга.
В идеале мы должны снять лишь тех баб которые прописаны в требованиях к проекту и совершить все 1000 актов с ними, что во многих случаях может существенно ускорить процесс. Это и есть переиспользование.
Но в жизни не всё так идеально. Допустим какая-то часть этих баб фригидна, или просто вызывает отвращение. В этом случае потратив некоторое время и усилия на поиск адекватных баб можно за пять минут долететь. Только успевай прерываться на обед. Кроме того, желательно, чтоб это были охуенно полиморфные бабы (по Синклеру). Например в техническом задании прописано X анальных актов и Y актов в нестандартных условиях (например на подъёмном кране без страховки), а баба начинает говорить что ты типа там свою елду мне в ачко без смазки не суй или там у нее ахуенная боязнь высоты - это некачественная (неполиморфная) баба.
В таких случаях можно поступать поразному, поменять неполиморфную бабу на другую, необязательно полиморфную, но с разработанным очком, или просто воспитать в духе постмодернизма, но в любом случае на это требуется время. Это называется refactoring, который, к слову, неотъемлимая часть экстремальной йобли, простите, экстремального программирования.
Если уж вспомнил XP, то позволю себе добавить пару слов в адрес ненавистного мне RUP который, блядь, придумали то ли старики-импатенты то ли юные девственники. Ну как вы можете относиться к человеку который пишет в тех задании, что через семь месяцев он будет ебать в жопу Машу Иванову, а потом прыгает вокруг этой Маши как последний добоёб узнав, что если он приблизицца к девственному очку Маши, то сразу получит лежащим рядом серпом по его же яйцам. А сзади к этому долбоёбу подбирается другой долбоёб - манагер со смазанным хуем наперевес и угрожая вставить свою елду в жопу бедного исполнителя вместе с натянутым на эту же жопу глазом, если тот не впендюрит Маше сию же минуту.
Аутсорсинг (outsourcing). Это когда мы часть работы отдаём сторонним исполнителям. Например нам лень ходить по барам в поисках женщин, опять же точно не известно, сколько времени и денег придётся затратить на данный процесс. В таких случаях имеет смысл просто заказать баб. Недостатки здесь ровно те же самые, что и в программных проектах, а именно:
- Товар, как правило, подгонят некачественный, а за полиморфизм и удачный реюзинг (обмен, доп. услуги и т.д. придётся доплачивать, иногда нехило).
- Клювом щёлкать нельзя. Аутсорсеры в основном берут почасовую оплату. Можно и на ночь, но дороже, да и хрен ли на них пялиться всю ночь.
- Гарантий успешной йобли никаких - можно всю ночь гонять водилу туда-сюда, башляя за доставку, и отбраковывая товар, и в результате нажраться в сопли, так и не поимев даже жалкого подобия секса.
По большому счёту - гавно технология, но допустимая как в программных проектах, так и в реальной жизне: если не все, то подавляющее большинство пользовались. Как мне тут небудуговоритькто подсказывает: лучше в таких случаях обращаться к "своим" уже не раз проверенным аутсорсерам ;)
Ну и конечно, не стоит недооценивать возможности проектов с открытым исходным кодом (open-source): честных давалок - не ищущих личной выгоды, а лишь делающих то, что им нравится.
А теперь возвращаясь к теме оценки временных затрат, я хочу спросить у читателя: Сколько времени потребуется команде из 10 девелуперов, для того, чтобы совершить 100 актов с как минимум 20 разными бабами, одна из которых весит 120 килограмм, другая... короче дополнительные функциональные требования можете придумать сами.
Лиричиское отступление №1: почему я не рисую (ненавижу) use case диаграммы:
Вот вам типичная диаграмма использования для нашего случая:
Без базару я бы не отказался иметь в документации по проекту use case диаграммы, нарисованные с приведённым здесь качеством, но лишь для удовлетворения своих морально-эстетитеческих потребностей. К сожалению все диаграммы, которые я видел за свою жизнь выглядят гораздо непрезентабельнее и несут смысла не больше чем данная картинка. Если на них долго смотреть то можно впасть в тихое охуение: пользователь входит в систему, пользователь выходит из ситстемы, пользователь меняет права другого пользователя. Не напоминает ли вам это комиксы? Саша входит в Машу, Саша выходит из Маши. Паша входит в Сашу когда тот теряет бдительность. Ахтунг бля!
Гуру любят аппелировать к тому, что картинки хорошо воспринимаются заказчиком. Хуйня! Заказчик тоже не дурак и любит картинки не более обычного человека, которому подсовывают для чтения энциклопедию для дошкольников с иллюстрациями, вызывающими скуку у любого гуманоида старше десяти лет.
Применительно к use case диагарммам, картинки полезны лишь в очень редких ситуациях, ну, например показать отношения генерализации между actors. Но я не вижу никакого смысла превращать проектную документацию в комикс, да еще и скучный, потому как долбоёбы его рисующие, прежде чем дойти до приведённой выше картинке, захуярят еще 20 картинок, описывающих способы использования ширинки, носков и ботинок...
Лирическое отступление №2: Большие компании и реюзинг.
У больших компаний есть некоторое преимущество, из которого можно как извлечь огромную пользу, так и нажить немало геморроя. Тот же "Новософт" всилу своего размера имел кучу баб в любой отдельно взятый момент времени. К сожалению, реюзингу там не уделялось никакого внимания. Теоретические верные попытки господина Гумирова загнать некоторых баб в персональный гарем "Новософта" (FL), а потом заставить всех девелуперов ебать этих баб привели к плачевным результатам.
Во-первых, проёб кучи бабок на поддержание жизни этих баб в гареме компании. Во-вторых, вследствии хуйовой архитектуры этих баб, а так-же неполиморфности (по Синклеру ;) привлечённых созданий, ёбля с этими бабами превращалась из процесса получения удовлетворения в процесс уламывания этих баб. Кроме того оказывалось, что у одной из них очко настолько раздолбанное, что без волшебных манипуляций добиться вообще ничего невозможно, а у других вдруг обнаруживалось полное отсутствие любых подходящих дырок.
Хотя при нормально поставленном реюзинге и гареме, конролируемом реальными мачо (по Maxelу) можно добиться мягко говоря неплохих результатов. Тогда не придётся оказываться в ситуации, когда взяв в пользование бабу из соседнего отдела, ты с удивлением обнаруживаешь, что баба даёт только после исполнения тобой Yesterday на баяне, в то время как другие сотрудники должны ее стимулировать мантрами из Бхагавад-гиты.
Лирическое отступление №3: О мачо, ламерах, и промежуточных звеньях.
Возвращаясь к теме полезности средних специалистов, давайте вернёмся к поставленному выше вопросу. Сколько времени потребуется 10 среднестатистическим жителям Новосибирска на 100 актов с 20 разными бабами. А теперь сравним: сколько времени потребуется команде КВН НГУ (сборной России по футболу, актёрам из сериала "Бригада" и т.д.) из 10 человек на выполнение той же самой задачи? Ответ очевиден: гораздо меньше. Таким образом, если у меня есть достаточно денег, я предпочитаю команду собранную из мачо. Однозначно и безусловно.
Полезность среднего девелупера я вижу лишь в еденичных случаях: ебать стодвадцатикиллограммовую бабу. И только в том случае если этот процесс не критичен для проекта. Разделение обязанностей между мачо и профессионалами тоже непростое занятие. Предстваим себе, что мачо снимают баб (определяют архитектуру) и приводят их для йобли средним девелуперам. Если баба без выебонов (обычная, среднеполиморфная баба без комплексов, желающая только того, чтобы её отимели), то средний, скорее всего справится.
В реальности же либо баба ему не даст (чувак просто не просечёт концепции), либо отимеет он ее неправильно (непоняв архитектуры и совершив кучу лишних телодвижений). Только не надо пиздеть что мачо должен еще подогнать среднему полную инструкцию по использованию данной бабы. Он быстрее отимеет ее сам, либо отдаст другому мачо, секущему фишку.
By Andrey Platov at December 3, 2003 06:06 AM