Коллективный разум: How to

Я нашел в MS дядьку, с которого дико тащусь.

Его зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OGL в SGI, писал по нему книжку, а сейчас вот архитектит в том числе D3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 20 и просветлился больше, чем за два предыдущих месяца. Читал его гуидлайны про API design и опять же радовался.

Отрывок на сегодня:

“DESIGN BY COMMITTEE. Avoid design by committee. There should be a single person with final say in the design …. and this person should have good architectural experience and instincts.”

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

Вот мне очень нравится Design Review и я всем его советую. Это когда перед тем как кодать что-то, надо об этом рассказать команде или еще кому, у кого есть время и понимание происходящего. Тебе обязательно наговорят кучу фидбека, вспомнят 10 тонких мест, о которых ты не подумал и предложат альтернатив. И часто окажется, что первая идея дизайна не идеальна, а может и вторая. Или неплоха, но нужно додумывать.

Если их фичи на тебя завязаны, то еще и посмотрят и прикинут как вы будете интегрироваться. Так как Design Review взаимный, то и ты будешь знать о той стороне. Кроме того, и знания людей о проекте расширяются и начинают больше пересекаться, и код твой понимать проще, и Code Review становится гораздо более осмысленным занятием.

Хорошо бы после этого обсуждения еще и записать основные принятые решения и почему. Конечно, с какой вам лично хочется детальностью, от детального Design Spec до коротенькой странички “overview and key decisions”.

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

Все это крайне полезно и обязательно нужно делать. Коллективный разум заруливает и побеждает.

И у этого всего только один catch – коллективное обсуждение не должно означать коллективных решений. Коллективный разум очень хорошо думает, но очень плохо принимает решения. Всегда должен быть один человек, который имеет право выбрать из предложенных альтернатив и их за и против. Понимая всю картину, осознавая все возможности, сказать “а вот с этим мы будем жить”, “мы выбираем вот такой трейдофф”, в конце концов, сказать “а вот на это мы положим хер”.

Иначе – превратится в коллективную безответственность и бесконечные споры. Я это прямо видел своими глазами, и не я один.

А у Дэвида это все – одной строчкой. Эх…

  • shodan

    “Всегда должен быть главный тупой.” :)

  • CEMEH

    Глобально – конечно. В конкретно девелопменте – обычно feature owners разные у разных фич.
    Вот Шодан, у вас есть design review? Чтобы на все non-minor фичи?

  • Tenchiken

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

  • shodan

    > Вот Шодан, у вас есть design review? Чтобы на все non-minor фичи?

    А как же.

    Я регулярно советуюсь с продюсером.

  • http://virtul.livejournal.com virtul

    >Коллективный разум очень хорошо думает, но очень плохо принимает решения.
    Осознал. Спасибо :)

  • http://www.codygain.com neteraser

    прекрасно :)

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

    делая игры стоит видеть в программировании как минимум не только инженерную дисциплину (а как по мне – и не столько). :)

    делая windows приходим к тому же выводу.

  • CEMEH

    > Я регулярно советуюсь с продюсером.
    Про решения в коде??? Это типа шутка такая?
    И остальные в команде – тоже с продюсером советуются?

  • shodan

    > Про решения в коде??? Это типа шутка такая?

    Ни разу не шутка.
    Он очень умный, кое-что понимает лучше меня.

    > И остальные в команде – тоже с продюсером советуются?

    Какие остальные?!
    :)

  • CEMEH

    Ай, я про Скайфоллен спрашивал. Мы же тут про геймдефф.

  • shodan

    > Ай, я про Скайфоллен спрашивал. Мы же тут про геймдефф.

    Как я тебя ловко наедул!!!

    Там большие и долгие изменения тоже вполне себе обсуждаются.
    Не с внешним продюсером, понятно, но обсуждаются.

  • dDIMA

    Отлично сказано. Компактно и емко.
    Хороший гвоздь в гроб сторонников разных базарных вече, принимающих коллективные неправильные решения.

  • CEMEH

    Я к этому всему хочу только добавить, что Design Review – это обязательная и необходимая вещь. Принцип Avoid Design by Comitee ее дополняет, а никак не перечеркивает. И разумеется отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу.
    То есть – коллективный разум таки действительно рулит. Решение которое ты примешь не рассказав и не посоветовавшись – будет хуже.

  • Dmitry Tyurev

    Советоваться нужно – факт. Брать варианты, которые лучше своего – туда же. Но ведь решения всегда принимает один. Как можно по-другому? Если нет одного человека, обладающего правом последнего голоса, то решение, вероятно, никогда не будет принято. Или ты имел в виду голосование? Если так, то решение одного опытного архитекта (выбранное по результатам обсуждения) скоре всего зарулит решение, полученное голосованием. Не говоря уже о том, что все решения по проекту должны формировать непротиворечивую архитектуру, а если решения принимаются голосванием, то это едва ли возможно.

  • CEMEH

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