Как стать автором
Обновить

Комментарии 96

Супер. Спасибо.
Очередной рационализаторский подход к иррациональному делу.

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

Вы прикалываетесь? По отдельности слова понятны, но предложения?
Управлять неопределенностью это очень, очень сильно.

Но за статью спасибо.
По-моему, гиблое дело применять такой аппарат при работе над ЛЮБЫМ проектом, не только в Сети. Люди - не константы, всегда (опять же по закону Мерфи) найдетс человек, который сдвинет все ваши диаграммы далеко за пределы буферов.

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

Текст классный (Roman_Mix уже отъехал), много букаф - но читать и вникать - извините.

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

Если интересно, как работаем мы - отпишитесь, попробую рассказать
Для меня вполне понятно откуда у статьи растут ноги. Когда бизнес целиком завязан на успешную продажу проектов и последующего их выполнения в соответствии со сроками и бюджетом, то тем кто планирует очень важно совершенствоваться в составлении планов. То что могут быть люди которые съедают буфер совершенно не отменяет того факта что бывают хорошие планы, а бывают плохие планы.
Согласен. Попробую расширить и подытожить.

Планы - планами. Замечательные такие планы - но результат зависит на 80% от исполнителей этого плана. Его не только составить-нарисовать надо, его надо соблюсти, потестировать систему, промотивировать исполнителей, утирая попутно сопли заказчику.

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

Ну а рассматривать все это в комплексе - тянет на кандидатскую.

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

Обеспечить качество и сроки - стремится выжать 100% из имеющихся исходных данных и ресурсов. И я даже погорячился насчет 20% успеха, которые выделил на грамотный план - в некоторых проектах он тянет на все 50%.
Отписываюсь, расскажите, пожалуйста.
Я управляю своими проектами исключительно "по наитию", без специального образования, подобных заумных статей и "брутальных терминов". Возможно, все эти вещи применимы для управления проектами запуска освоения новых нефтяных источников, но для разработки в вебе это чересчур.
Однако, мне всегда интересен конкретный опыт занятых в той же области, что и я.
Кратко: есть deadline, установленный по утвержденному с заказчиком плану. За 2-3 суток до deadline'а ставится внутренний redline. Итерация этапа (milestone - мы этим словом пользуемся) оканчивается к redline'у - у нас появляется буфер для тестирования, исправления багов.

В этот буфер часть участников плотно общается с QA, фиксит баги (удается за этот буфер найти и обезвредить процентов 80%-90%).
Вторая половина (lead и его свита - скажем так) идет дальше и начинает следующую итерацию.

1. Выкатываем заказчику на deadline с svn'а ту версию, которая должна быть по milestone'у
2. Играем на опережение - буфер может расти к концу проекта, может быть потрачен на задачи, на которые время было рассчитано неверно (менеджер с каждым разом все точнее бьет в цель).

Естественно, заказчик и менеджер также должны утверждать следующий milestone минимум за несколько дней до deadline'а.

Думаю, порядок ясен))
Ну понятно, это вполне стандартная схема. Еще раз убеждаюсь, что данный пост предназначен для других задач, вроде "моделирования стохастических процессов в бизнесе"
Ну а мы по старинке :)
НЛО прилетело и опубликовало эту надпись здесь
Согласен, когда уровни моих разработок и проектов уткнутся в подобную необходимость, я достану этот пост из избранного )
Лучше пусть всю жизнь пылится в избранном, если это для людей. Ибо такой подход (я его прочитал наконец-то) это вообще что-то с чем-то.
Коллеги, это клиника, претендующая на уникальность. Нарисовать нормальное распределение, немножко его ужать справа (график разъ) и радостно заявить о буфере безопасности. Н-да. Ладно, закон Паретто автор не читал, ладно он не смотрел как работают люди, ладно он сам никогда не пытался организовать работу людей. Но, блин, хотя бы подумать больше 15 минут можно? Потому что тогда придет в голову простая и незатейливая мысль, что в реальном мире очень мало линейной работы, выполняемой человеками, что работа команды зависит от действий каждого члена этой команды, часто без результата, полученного одним человеком, другой работать не начнет. Где это все в вышепредлагаемой схеме? Где синхронизация отедлов? Где, наконец, потери от организационной структуры? Где непрямые издержки? Где трансакционные издержки?
Всё правильно говорите. И автор поста прав по-своему.
Как разживусь кармой, напишу в этот блог пост об управлении проектами с ЧЕЛОВЕЧЕСКОЙ точки зрения, где ни один из этих законов работать не будет, но при этом, с данным вопросом сталкиваются гораздо чаще, причем на проектах любого уровня.
НЛО прилетело и опубликовало эту надпись здесь
естественно эмоционально, тут же общение людей происходит, а не роботов.
НЛО прилетело и опубликовало эту надпись здесь
В соответствии с PMBOK есть организации у которых образ действия операционный, а есть проектный. Насколько я понял по Вашим статьям у вас больше операционный образ действия, когда надо делать какую-то работу, а не то что называется проектом.

Про зависимости между задачами в этом статье не забывается. На счет остальных издержек мне не совсем понятно. Если есть риски связанные с тем что синхронизация отделов повлияет на сроки сдачи проекта, то с ними надо поступать как с обычными рисками, т.е. продавать, обходить, и т.д.

Другие издержки менеджеру проекта обычно не очень интересны, это больше к тем кто управляет финансами и портфелем проектов.
Вот она и проблема: другие издержки никому не интересны. Вместе с этим, именно другие издержки и влияют на дело в целом. Простенький пример: вашим сотрудникам надо работать через интернет, но сеть не то чтобы лежит, она валяется. Вместе с этим, вам надо, чтобы приходили и письма, которые кто-нибудь фильтровал. Админ один. Что ему делать? Пример простенький, но вполне в схемку не впимсывающийся.
Ок. Вот второй пример: у вас есть 10 программеров, которым в течение месяца надо сделать сайт. Один пишет безопасность, второй пытается оптимизировать запросы к БД, третий разрабатывает ЦМС. Вопрос: как хотя бы этих трех синхронизировать? Запланировать, что безопасность следует написать к 10 числу, а ЦМС к 13. Дык, тут такое количество проблем вылезет, что решать их все равно придется в режиме дедлайна.
Ну управление проектом и организация эффективного бизнеса разные вещи. В идеале компания должна предоставить среду для менеджера проектов, чтобы оне не думал про эти вещи, а работал в своем "проектном" мирке подключая ресурсы компании (исполнителей, сисадминов, юристов, и т.д.) когда необходимо. Эта задача уровня выше, чем выполнение какого-то конкретного проекта в срок.

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

Вообще если задача изначальна поставлена так что в течении месяца десяти программистам надо сделать сайт - это плохой сетап. Хороший сетап - когда ПМ получает хорошо оформленные требования (от заказчика, продукт менеджера, и т.д.), делает свою оценку по ним и отвечает за реализацию продукта на основе этих требований в рамках бюджета и в срок.
А если идеала не ссуществует?
А если задача стоит такая, какая она есть?
А если кроме нужно время для... еще и работать пытаться мотивировать сотрудников? Понимаете, я вовсе не против каких-то подходов. Просто они настолько смешны, что я не могу удержаться от иронии. :)
Ну такие эвристики из статьи больше подоходят для организаций типа где мне приходится работать. Вот случае когда на вход получаешь требования и нужно сказать когда будет готов результат и сколько это будет стоить, после чего нужно сделать по этой оценке.

Когда задача ставится таким образом, что надо успеть за месяц, то фактически никто за нее не отвечает. Что если задачу в принципе нельзя сделать за месяц? Кто согласился что сделает ее за месяц? Кто виноват если через месяц нет сайта?
Вы понимаете, в чем фишка. КАк писали Стругацкие в Понедельнике, интерес не в том, чтобы найти решение решаемой задачи, а в том, чтобы найти решение задачи решение не имеющей.
Ну это кому как )
Типа: "Нам тут думать некогда, работать нужно. Все же ж сложно и непонятно, задачу фиг поймешь, сотрудников мотивировать, президент новый, а вы со своими рисками и методологиями лезете."
Сформулируйте свое понимание риска и свое понимание неопределенности. Я настаиваю на том, что неопределнность не может быть управляема. Можно выработать набор мер, направленных на компенсацию возможных отрицательных последствий неопределенности. К примеру, елси вы не уверены, что ваши сотрудники сделают проект через месяц, то можно заложить, что к 15 числу нужно сделать 70% проекта. Если к 15 числу 70% проекта сделано не будет, то к 17 надо быть способным найти людей, которые подтянут проект к 20 числу до этих 70%. Тут я соглашусь (со значительными оговорками). Тем не менее, все пишут о каком-то буфере. Отсюда я и делаю вывод, что подобные интеллектуальные извраты вещь очень интересная, значимая, но неприменимая на практике.
Риск вида "проект не будет сделан вовремя" обычно слишком выского уровня, чтобы с ним можно было иметь дела менеджеру проекта (хотя данная статья призвана помочь уменьшить вероятность именно такого риска). Это скорее риск для бизнеса заказывающего проект. Вообще нужно разделять эти роли, у бизнеса и у проекта могут быть противоположные интересы )

Лично я имею в виду стандартные определения, которые можно например на википедии найти. http://en.wikipedia.org/wiki/Uncertainty, http://en.wikipedia.org/wiki/Risk_manage…
См. ссылки на википедию.

Пример управления неопределенностью: мы не знаем, какая из технологий (А, Б, В) лучше подойдет нам для реализации проекта. Соответственно, не знаем каких лучше подбирать специалистов и сколько займет проект.

Поэтому мы сначала тратим часть времени на исследования и возможно POC, после чего неопределенность в вопросе наиболее подоходящей технологии исчезает.

(Остается только риск, что мы ее неправильно выбрали :)
Ну вот, видите вы уже признали, что кроме существования полубредовых РМВОК есть еще интересные вещи. То, о чем вы говорите является обычной задачей на оптиум управления с минимизацией рисков. Читайте внимательнее: минимазация рисков, но уж никак не управление ими.
Минимизация - это одна из стратигий в управлении рисками.
Хм, я бы даже сказал, что они все исходят из этого утверждения. В общем, подводя итог вышесказнному: стратегия может быть одна — основанная на математическом подходе и после прочтения учебника по теории вероятностей. А вышеназванный подход это попытка объяснить ребенку, откуда появляются дети. Сделать в принципе можно, только стыдно.
Да нет, стратегий может быть несколько. Например идеально (и иногда получается) когда риск продается. Например, если стороней библиотекой поддерживается функционал, то время решения нашей задачи - 1 день, если не поддерживается - то 2 недели чтобы написать с нуля. Если изначально заложить в план 2 недели и заказчик соглашается - то можно считать что риск продан.
Ну задача-то не только в том, чтобы написать. И то в примере с библиотекой можно за уши притянуть то, что риск минимизируется, поскольку перекладывается на других людей. Проблема в том, что это и не риск в полном смысле. Вот если вы работаете, а главный архитектор заболевает, вот тогда это риск. :)
Если я правильно понял вашу точку зрения, риск - это обязательно то что нельзя предвидеть заранее, а если можно предвидеть - то это не риск :).
Приблизительно да. Посколько все остальное поддается прогнозированию в рамках принятых математических моделей. :)
Понятно. Будьте готовы что вас будут неправильно понимать те кто пользуется терминологий PMBOK, Risk Management, etc.
Вряд ли я с ними когда-то повстречаюсь. А так я вполне готов мириться с их агрессией. :)
Если кратко, то выглядит это так: в дедлайн делается 80% нужной работе. Во время до дедлайна делается 20%. Гениально, коллега.
Озвучьте размеры ваших проектов в трудозатратах.
Все в порядке, так и делайте дальше. Должен же кто-то выполнять роль тех, на чьих ошибках остальные учатся.
"гиблое дело применять такой аппарат при работе над ЛЮБЫМ проектом, не только в Сети. Люди - не константы, всегда (опять же по закону Мерфи) найдетс человек, который сдвинет все ваши диаграммы далеко за пределы буферов"

Поздравляю - Вы только что объявили бессмысленными любые попытки управлять чем-либо, связанным с людьми. Ну да, люди же - не константы. Нахуя мне управлять космическим кораблем, если в ней человек? Он же сейчас там все тумблеры с дури понажимает, и все взорвется!!!

Кстати, процесс о котором Вы говорите ниже - самый обычный процесс, адаптированный для конкретно _Вашей_ команды и _Вашего_ типа проектов, и он, несмотря на все рассуждения про "гиблое дело, ..." и т.д. - вполне реально помогает Вам здесь и сейчас бороться с неопределенностью и рисками.
Ну если говорят об управление рисками, то почему бы не говорить об управлении неопределенностью.
потому что никто ими не управляет. Ни риском, ни неопределенностью. Управляемая неопределенность это миф. Это такой бред, который даже с элементарной логикой не дружит.
Все менеджеры/архитекторы проектов так или иначе управляют рисками, или инстинктивно или по какому-нибудь учебнику.
Ну неужели не понятно, что это логический бред? Управление рисками. Еще больший бред это управление неопределенностью (риск является ее частью). Бред потому, что неопределенность неопределена, а вот управление вполне себе определено. Хотя бы по наличию объекта управления.
Управление рисками это тоже самое, что управление машиной без тормозов с завязанными глазами, без рук и под советы 4 окружающих вас блондинок. В данной ситуации поведение водителя может быть в принципе любым, результат может быть тоже любым, но вот зависимость от поведения водителя и результата будет весьма сомнительным.
Чапек К. "Двенадцать приемов литературной полемики"

11. Impossibile (здесь: нельзя допускать — лат.) . Не допускать, чтобы противник хоть в чем-нибудь оказался прав. Стоит признать за ним хоть крупицу ума и истины — проиграна вся полемика. Если иную фразу нельзя опровергнуть, всегда еще остается возможность сказать: "Господин Икс берется меня поучать...", или "Господин Икс оперирует такими плоскими и давно известными истинами, как его "открытие...", или "Дивись весь мир! Слепая курица нашла зерно и теперь кудахчет, что...". Словом, всегда что-нибудь да найдется, не так ли?
Разумеется. Вы вот привели цитату.
Почему бред? Под управлением рисками подразумевается вполне конкретный набор работ. Если минимально, то перед подготовкой плана проекта можно иметь список рисков и понимать что какие-то риски в случае их возникновения включены в план,а какие-то нет. Бывают конечно самые общие риски - вроде задача была недооценена, заняла больше времени чем предполагалась, и т.д. В данной статье как раз описано как минимизировать ущебр от этих рисков по проекту в целом. Бывают совершенно конкретные риски, которых ближе к концу проекта становится все меньше и меньше.

Вообще считается что уровень неопределенности к началу проекта высок, а к концу проекта низок. Когда неопределенностью управляют - это значит что у менеджера есть понимание того как именно она уменьшается )
Для управления неопределенностью нужен объект управления. В условиях неопределенности определить объект нельзя. Если проводятся какие-то мероприятия, которые проводят все или которые логичны, это просто означает, что управление неопределенностью пытаются осущствить при помощи шаманских плясок. :) Я не уверен, что это не эффективно, я также сомневаюсь и в эффективности.
Примеры неопределенностей:
- через неделю становится понятно ложится ли человек в больницу на месяц или нет
- является ли third party код достаточно стабильных для использования в данном проекте
- интеграция с продуктом заказчика может занять неопределенное время.

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

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

Неблагодарное дело - учить нубов жизни, особенно если учиться они не собираются.

Пусть товарищ снизойдет с высоты своей кармы и для начала ознакомится с PMBOK или хотя бы с вводной информацией по управлению рисками. После этого может быть хоть какой-то разговор, так - трата времени...
Наверное и про управление рисками на храбре будут посты :)
Да не будут посты: риски вещь иррациональная, поэтому тут дохрена мистики и не подходит к технарям. Не потому, что они тупые, а потому, что не в их это системе координат.
Ну, сдается мне, что это мне. Ок. Объясняю специалистам по РМВОК и прочих страшных слов. Задача, описываемая вами, требует типично математического подхода. В кратце необходимо найти оптиум управления по многомерным вариациям (если вы с высоты своего интеллекта способны понять о чем я). После чего можно извратиться и начать описывать при помощи тензоров (хе-хе), а возможность смены состояния системы (ляжет — не ляжет в больничку) дивергенцией тензора по времени. После чего можно забацать модель, основанную на нечеткой логике +/- другие извраты. А в моделке предусмотреть возможность ввода неверных данных (вы понимаете, что это значит?). На основе всего этого построить соответствующую модель. Вот такую модель я согласен обсудить, ибо интересно мне это.
Боюсь, Вам придется заниматься мозгоебством в одиночестве.
что ж так агрессивно?
Где вы взяли неопределенность? Вы работаете в системе, параметры которой определены (ляжет не ляжет — это не неопределенность). Неопределенностью можно назвать следующее: кто ляжет, когда ляжет, ляжет ли или что-то другое (останется дома и работать не сможет)? То, о чем вы говорите, подчиняется обычной простенькой задачкой, в которой следует искать оптиум управления по многомерным вариациям (в общем случае). И просто с некоторыми неопределенными параметрами в вашем примере. Вопрос, это что так сложно? Если бы автор не пытался совокупить теорию вероятностей с наукой принятия правильных решений в гуманитарном ее понимании, он бы действительно занимался управлением.
является задачкой. Ивзините.
Любую неопределенность можно как-то определить что с ней можно работать. Если неопределенности возникают постоянно и неожиданно как на поле боя - ну значит такая среда, где важнее оперативное принятие решений. Думаю под управлением можно понимать такие неопределенности которые можно идентифицировать заблаговременно, и как-то с ними работать.
Давайте конкретный пример. Потому чвто определить можно все, но будет ли это соответствовать действительности?
Лучше вы дайте пример определенности, с которой нельзя работать. Как только формируется описание неопределенности, так сразу придут на ум стратегии как можно с ней поступить, или как лучше разбить эту неопределенность на вероятные исходы. Высокоуровневые неопределенности вроде "проект не будет выполнен в срок" лучше не рассматривать.

Важно понимать что, что успех проекта может зависит от того или иного развития событий в рамках описанной неопределенности.
Неопределенность проявляется и в том, чтобы нельзя было ее определить. ;)
Так вот, простая задача: обеспечить получение прибыли в заданном размере через 2 месяца. неопределенность тут во всем. :)
Не, так не интересно. Есть ли какой-нибудь план по по достижению прибыли? Например, покупаем 40 сковородок по 20р и продаем по 60р в результате получаем нужную прибыль. Вот когда есть план можно искать неопределенности, типа "у нас же никто не купит сковородки по 60р о_О".
покупаем материалы — делаем дизайнерские сковородки == продаем их. Вот тут и наступают риски.
суть понятна. какие программные продукты из популярных и доступных с этим работают? можно привести небольшой пример, скажем, для процесса разработки сайта или пуска сервиса?

кто автор? олег клименко — это вы? несколько непонятна последняя фраза. кросспост не особо радует, а если это вы и есть — так и пишите

статья идеальна с точки зрения оформления. гранд респект
Спасибо за статью.

По Стивену Кови, с которым авторы, безусловно, перекликаются, наибольшая часть работы выполняется когда цель важна, но не критична по времени. Задача менеджера, соответственно, регулировать эти два параметра, мотивировать и не создавать авралов, если упрощенно.
По этому методу оба параметра в описанном методе и правда регулируются, т.к. единовременно задача всегда одна, следовательно, важность единственной задачи заведомо выше ее же в числе многих, и есть заранее запланированный запас (буфер) времени.
Но подача уж слишком мудреная. На основе тех здравых мыслей, коих в статье много, можно сделать схему проще, или эту проще описать.
Вот многие основываются на milestone'ах диаграмм Гантта - но ведь в каждый из них входит несколько задач!

Мне больше импонирует подход с короткими итерациями, который используется в XP. Тут задача всегда единственна и максимально изолированная. Сел, сделал, прогнал тесты, пошел дальше. Не зацикливаешься. Согласны?
Сейчас занимаюсь моделированием стохастических процессов в бизнесе. Очень хорошо если бы менеджеры по управлению проектами включали недетерминированость сроков и ресурсов в свои планы. За статью плюс.
Прекраный материал, нечасто тут встречается. (А Голдрат не "Элияху" случаем? я видел такой вариант перевода в бумажной литературе)
В статье почему-то не упоминается, что Метод критической цепи является развитием Метода критического пути, только с добавлением буферов, покрывающих риски.
Просто не осилил.
Это для роботов, а не для людей.
НЛО прилетело и опубликовало эту надпись здесь
Работаю дизайнером в маленькой компании.
Пытался донести до всех что при малых ресурсах планирование должно быть еще более важно. На что все только улыбаются и разводят руками, типа зачем оно нам, раньше ведь и без планирования работали.
На моей практике, диаграмму ганта (он с одной т) никто действительно не соблюдает. Руководители проектов исходят из того, что перед ними обычные в общем-то люди, поэтому они и не пытаются им навязать подобный стиль мышления. Т.е. руководители проектов знают, с кем они работают.
НЛО прилетело и опубликовало эту надпись здесь
люблю слова, неподкрепленные практикой.
Про т — всегда писал с одной. Но буду знать, что правильно с двумя. :)
Планирование д.б. адаптивным. :)
НЛО прилетело и опубликовало эту надпись здесь
тогда остамся при своих мнениях.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вот приличный заголовок, что и не говори. На первой странице. Даже и не важно что там внутри. Просто приятно открыть Хабр в присутствии посторонних, что бы все видели, что читаю я - Метод критической цепи: эффективное управление проектами. Сразу уважение у окружающих людей. Общечеловеческая жизненная карма растёт. Близкие опять же понимают - я делом занят, а не в какой-то там социальной сети вишу.

Ото зайдёшь бывает, а там что-нить типа - Кармазадроты готовят очередную революцию. Тьфу... Да. Стыдоба.
Пойду перекурю вашу мысль. Уж очень она внушительная.
О, а я как раз по этой теме диплом бакалавра защищал :) Писал на Ruby реализацию этого дела - высчитывало все упомянутые параметры и рисовало красивый график. Спасибо за статью.
Где можно посмотреть на ваш инструмент в действии?
К сожалению нигде - валяется в сыром виде где-то на винте - защитился с тем, что успел написать, дальше развивать не стал. :)
Давай мыл, пришлю что есть :)
А можно посмотреть ваш проект и дипломную работу? Очень было интересно почитать и то и другое.
Я поищу чуть позже и вышлю, что есть. Но предупреждаю сразу: половина работы - паливо чистейшей воды, - мне было интересно реализовать сам алгоритм на Ruby, но оформить это в полноценный продукт, довести до ума и тем более написать хорошо сопровождающий документ интереса уже не хватило. Тем более, что преподы из нашей комиссии всё равно ничего бы не поняли - они по пониманию IT остались где-то в 80х.
Мне все равно интересно будет посмотреть.
Плюс вам в карму. Спасибо за замечательную статью.
НЛО прилетело и опубликовало эту надпись здесь
Та не парься, иди лучше в дрочильную машину чем-нибудь потыкай.

Пеар: http://ohmygod.habrahabr.ru/blog
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.