“Правила Ашманова” – доклад на РИТ-2007

Рубрика: Development | 19 April 2007, 14:29 | Vadim Voituk

Игорь Ашманов на РИТ2007 простыми словами рассказывает о Software-Engineering процессах в web-разработке.
Must have для всех разработчиков.

Правила Ашманова (Игорь Ашманов РИТ-2007) (61.66Mb)

И текстовая версия: часть 1, часть 2.

Комментариев: 6

6 Responses to ““Правила Ашманова” – доклад на РИТ-2007”

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

  1. Juriy

    Я с докладчиком несколько не согласен. Да что тут говорить, я с ним не согласен вообще. Конечно, он крут, и все такое… но это еще не повод.

    Ашманов говорит что описанные процессы и процедуры не сработают, из-за того, что есть человеческий фактор, и люди не идеальны. Но для того, чтобы компенсировать “не идеальность” вводят процесс управления рисками, задача которого повысить вероятность успешного прохождения процедуры.
    Конечно, люди не идеальны, и риски есть. Но Ашманов не говорит ни слова о том, как эти риски обойти. Конечно, заказчику можно сказать: “c’est la vive, мы сделаем проект тогда, когда мы сделаем, потому что “Риски”. Но заказчик этого не поймет.

    “Обещания не всегда выполняются и люди не всегда разумные…” – вот для таких случаев, подписывают документ, вроде SLA, который заставляет людей выполнять обещания. Короче, это тоже не есть проблема процессного подхода: не берите на работу сотрудников, которые не справляются с работой.

    “Идея, что, если программу правильно спроектировать, задокументировать [...] то она будет работать – не имеет ничего общего с практикой программирования” – замечательная фраза, я на это смогу сказать только: “если программу не проектировать и не документировать, то шансы что она будет работать вообще стремятся к нулю”.

    “Расходы на процедуры слишком велики. Сертификация CMM или ISO может стоить…” – для того, чтобы применять процессный подход, вовсе не обязательно проходить сертификацию. Аргумент не принят.

    “В веб-разработке [...] нет возможности платить оверхед за документирование” – а что будет потом, когда разработчик, который собирал правое полушарие ядра системы уедет к бабушке в деревню? Сколько времени потребуется для того чтобы разобрать за ним его код, который в условиях постоянной гонки за сроками, будет далеко не идеальным?

    “Есть объективные препятствия для того, чтобы правильно сделанный проект привел к хорошему результату” – нет, ну это вообще перла. Так что, к хорошему результату приводят неправильно сделанные проекты? :-D

    Ну и дальше, про “разные интересы сторон” – чьи интересы Ашманов представляет тут? Разработчика, менеджера, или топ менеджера?

    Замечательно описаны интересы программиста: “платят нормально, ну и хорошо”, может я сужу по себе, но я не согласен. Если бы это было бы так, я бы сидел в Attack Software и писал игрушки на J2ME, рассуждая о том, как космические корабли бороздят просторы большого театра.

    “Программисты [...] совершенно не умеют общаться ” – нет, это некоторые менеджеры не умеют общаться с программистами. Ни разу не сталкивался с такой проблемой, честно.

    “Программист думает, что он – что-то вроде ученого …” – это отношение к людям – подчеркнуто-пренебрежительное – возможно и етсь корень проблем. Я бы с таким манагером долго не протянул. Послал бы подальше, и нашел бы компанию, где к программистам относятся с элементарным уважением.

    “Любые планы собранные путем оценок снизу – абсолютно нереальны” – тогда приходим к тому, что оценивать проект вообще невозможно. Кто будет оценивать сроки? Гуманитарии, которые “тоже могут управлять проектами”. Есть еще вариант – оценивать на основании предыдущего опыта. Но при отсутствии системного (процессного) подхода этот опыт не собирается и не фиксируется.

    “Менеджер старается планов не писать” – опять-таки, значит с него этих планов не требуют. Это естественное стремление каждого человека, снизить свою ответственность. Вот и получается, менеджер старается не писать планы, программист забивает на документацию… Это и есть результат отсутствия систематики и процессов.

    “Можно собирать команду, которую вы холите и лелеете, в нашей команде – это так… ” – вот и стало ясно откуда забивание на процессы. В такой уникальной команде – они может и не нужны. У них было 20 лет, чтобы методично и самостоятельно перенаступать на все грабли. В большинстве реальных команд такого времени нет.

    Короче, много деструктива, а конструктива мало, я зачислил время: конструктива из всего доклада – минут 5 всего.

    Ашманов воспринимает проектный менеджмент как эзотерику: “Для этого [успешного управления] надо улавливать тонкие сигналы…”, “вам нужна интуиция чтобы это понять…”, “трудно это понять…”, “вы просто чувствуете, что что-то не то…”, “тонкие сигналы ничто не заменит” ну и так далее.

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

  2. vadim

    Юра,

    Фразу “Сертификация CMM или ISO может стоить…” ты вырвал из контекста – там говорилось не о стоимости самой сертификации, а о том, сколько её наличие добавляет к срокам. Говорилось о 20%.

  3. vadim

    Выводов каких-то я не дождался – запись закончилась.
    В принципе не могу спорить с тезисами, какие привел Юра (уж больно долго мы с ним программной инженерией страдали :), но пищу для ума этот доклад все-таки дал.
    Потому вердикт: 32 минуты не были потрачены зря.

  4. Juriy

    Да, насчет фразы с CMM ты прав. Я переслушал запись и понял этот нюанс.
    Но все-таки интересно, как у Ашманова работают люди. Про свои методики он ни слова не сказал.

  5. Скакунов Александр

    А мне не понравилось, вместо пищи для ума какие-то полуфабрикаты: чувак может и гений, но объяснить по делу или не хочет, или не может. C’est la vie :]

  6. vadim

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

Leave a Reply