Здравствуйте, denis miller, Вы писали:
А>>2. Коллективное принятие решений на основе консенсуса по ключевым вопросам проекта
Увы. При таком подходе и наличии в команде хотя бы двух сильных лидеров с разными взглядами проект катится к провалу — сколько раз такое наблюдал. Есть архитектор(ы), предлагающие решения и есть ПМ, утверждающий то или иное предложение. Иначе мы получаем ситуацию в проекте, аналогичную имеющейся сейчас на Украине или в ЕС.
Искренне рад за вас, если вы действительно работаете в атмосфере Круглого стола, но король Артур все равно необходим и я уверен, он у вас есть.
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
.... _FR>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Попробую и я дать свое определение:
Командной работой называется одновременная работа нескольких человек над общей задачей (задачами), включающая общение между участниками и использование ими результатов работы друг друга.
Всякие процессы и тулзы типа SVN, трекеров багов и запросов — это инструменты, облегчающие командную работу при их правильном применении, и не более того.
А вот что такое команда и чем определяется ее качество — это я здесь написать не возьмусь, ибо есть миллион определений и все правильные. Ключевое слово — синергетический эффект.
Здравствуйте, nvb, Вы писали:
nvb>Попробую и я дать свое определение: nvb>Командной работой называется одновременная работа нескольких человек над общей задачей (задачами), включающая общение между участниками и использование ими результатов работы друг друга.
Сам хотел что-то подобное написать.
Принципиально то, что люди достаточно интенсивно используют результаты работы друг-друга.
Если это не так, то это не командная работа, а работа нескольких индивидуальностей над общей задачей.
Командная работа иногда позволяет делать то, что без нее не сделать нельзя. Например, большой группой накинуться на одну задачу и сделать ее за более короткий календарный срок (пусть и, возможно, за большее количество человекочасов).
Соответственно, если человек умеет хорошо работать в таком режиме, когда от него зависят другие и он зависит от кого-то, то он умеет хорошо работать командно.
Здравствуйте, MozgC, Вы писали:
_FR>>Кстати, о "дворовых командах": может быть тренерский штаб и прочая иерархия нужны лишь потому, что игроков в профессиональном футболе не пять-шесть-семь, а двадцать с лишним? То есть небольшая команда лучше сама себя организует, а лидер нужен только тогда, когда участников "много"?
MC>Зачастую бывает именно так, но наверное это зависит от уровня участников. Например если уровень невысокий (не сильно опытные разработчики), то лидер им нужен.
А если высокий, то нужен тем более.
Задача: написать принципиально новую операционку. Ресурсы: 10 человек уровня Линуса Торвальдса c равными правами + (облегчим задачу) 200 человек кодеров, тестеров, техписателей, тимлидов и прочих. Впрочем, их можно пока не нанимать — важно понимать, что они будут при необходимости.
Вы представляете себе, что там будет твориться через месяц?
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается?
А вы не спрашивали, что под этим понимают те кто этим интересовался ?
_FR>Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
Обычно что-то вроде "пастись вместе со стадом"
nvb>Искренне рад за вас, если вы действительно работаете в атмосфере Круглого стола, но король Артур все равно необходим и я уверен, он у вас есть.
Понимаю. Но не разделяю
Консенсус — критический важная штуковина. Причем это не показательная штука, что типа все "за", именно чтобы каждый в душе поддержал решение. Чтобы команда вышла на такой уровень нужно работать с командой. В Аджайл мире есть спец роль для этой цели — аджайл коуч или скрам мастер.
Ранее паттерн здесь озвучивался Проект = Команда, который помогает прийти к общему в любых вопросах. Но нужно знать как юзать это . Поэтому если команда выступает не как единный механизм, то это отразиться на реальной реализации. Если два человека не могут договориться, это означает, что хоть формально один задавит другого. Но последнее слова за реализацией. И это скрытый конфликт — и он ещё аукнеться. Поэтому круглый стол — это наше все. Да к тому же есть техники как культуру консенсуса развивать в команде.
Здравствуйте, denis miller, Вы писали:
nvb>>Искренне рад за вас, если вы действительно работаете в атмосфере Круглого стола, но король Артур все равно необходим и я уверен, он у вас есть.
DM>Понимаю. Но не разделяю
DM>Консенсус — критический важная штуковина. Причем это не показательная штука, что типа все "за", именно чтобы каждый в душе поддержал решение. Чтобы команда вышла на такой уровень нужно работать с командой. В Аджайл мире есть спец роль для этой цели — аджайл коуч или скрам мастер.
Именно. А еще можно запустить по телевизору такую серию программ, чтобы после их просмотра не было преступлений, все уступали бабушкам место в метро и не ругались матом. А сэкономленные таким образом на охране правопорядка деньги можно направить в детские дома. Но почему-то не получается...
Есть множество способов решения конфликтов. Вы говорите лишь про один вариант — интеграцию. Кроме них есть еще силовое решение, сглаживание, компромисс (это не то же, что сглаживание)... При наличии времени и соответствующих скиллов у руководителя проекта — несомненно, лучший выбор. Но если этого нет — приходится прибегать к остальным.
DM>Ранее паттерн здесь озвучивался Проект = Команда, который помогает прийти к общему в любых вопросах. Но нужно знать как юзать это . Поэтому если команда выступает не как единный механизм, то это отразиться на реальной реализации. Если два человека не могут договориться, это означает, что хоть формально один задавит другого. Но последнее слова за реализацией. И это скрытый конфликт — и он ещё аукнеться. Поэтому круглый стол — это наше все. Да к тому же есть техники как культуру консенсуса развивать в команде.
Отразится. Аукнется. Задавит. Печально. А с чего вы вообще взяли, что весь мир работает по Аджайлу? А если нет?
Вот пример. Вы работаете в организации. Она включает в себя юристов, финансистов, бухгалтеров, уборщиц, хозслужбы, айтишников. По статистике, 90% юристов свою работу не любят, я уж не говорю про остальных. То есть вы с командой проекта находитесь в некоторой ойкумене, афинском социализме, и окружающие работают на вас, вне зависимости, нравится это им или нет. Если же вы займетесь мотивацией уборщиц, то у вас не будет хватать времени на проект.
Теперь давайте эту ойкумену сузим. Предположим, есть три человека, отвечающие за архитектуру и живущие в мире друг с другом. Как в любом проекте, в нем есть несогласные, на нижнем уровне — скажем, свежеиспеченный кодер. Вам не удастся за приемлемое время объяснить кодеру-новичку, зачем нужно комментировать код — т.е. вы примените силовое решение, может быть, сославшись на правила кодирования, принятые в компании. То же самое случится, если в вашу команду придет другой человек, который работал, например, с Перфорсом, а у вас используется СВН. Опять силовое решение, опять демотивация.
Сужаем нашу ойкумену дальше. Один из архитекторов предлагает потрясающе красивое решение, но увы — оно не укладывается в бюджет заказной разработки. То есть укладывается, но за счет отказа от половины тестов. Архитектор со своей идеей так просто не расстанется — этому будет предшествовать неделя бесед, при этом оба собеседника должны быть вменяемы и один из них должен пройти через тренинг по разрешению конфликтов. Если же хотя бы одного слагаемого нет в наличии — что делать?
РМ постоянно работает с рисками. Есть риск демотивации участников и есть риск провалить проект, если все управленческие усилия и время направить на мотивацию участников. Приходится выбирать.
Я сам предпочитаю интеграцию и, если есть возможность, разрешаю конфликты именно так. Но это возможно далеко не всегда, увы.
Здравствуйте, _FRED_, Вы писали:
_FR>Отсюда и любопытство: что вы называете "командной работой"?
Характеристики команды
ясность общих ценностей и целей,
доверие, взаимный контроль, взаимопомощь и взаимозаменяемость,
коллективная ответственность за результаты труда,
самоорганизация и самоуправление,
всемерное развитие и использование индивидуального и группового потенциалов.
Группа vs. команда
Цель
Гр. Ставиться узкая задача, общие цели не проясняются.
К. Ясные, принятие всеми цели и стратегия их достижения.
Участие в работе
Гр. Выполнение должностных инструкций и распоряжений.
К. Активная позиция, нацеленность на результат, личная ответственность.
Ролевая структура
Гр. Строгое распределение ролей, должностей, обязанностей.
К. Разделение компетенций. Гибкая структура. Ротация ролей.
Руководство
Гр. Администрирование, наличие формального лидера-начальника.
К. Лидерство на основе компетентности и доверия, наставничество, помощь и поддержка.
Принятие решений
Гр. В основном приказы, и решения принятые большинством.
К. Эффективные процедуры принятия решений на основе доверия и взаимовыгоды.
Конфликты
Гр. Замалчивание, сокрытие, игнорирование.
К. Признание, интеллектуальная конкуренция, эффективное разрешение: «мы по одну сторону баррикады, а проблема – с другой».
Взаимодействие
Гр. Закрытость, избегание критики, принцип «не высовываться».
К. Доверие, свобода, проявление инициативы.
Коммуникация
Гр. Через формального лидера служебная переписка.
К. Открытость. Уверенность друг в друге и взаимное уважение.
Творчество
Гр. Стереотипность, работа по правилам.
К. Гибкость и адаптивность. Непрерывное совершенствование и рост компетенций. Раскрытие творческого потенциала каждого.
Пример
Гр. Гребцы на байдарке на гребном канале.
К. Команда туристов-водников, которые сплавляются по горной реке.
Командный игрок
Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело.
Постоянно приобретет новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег.
Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги.
Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению.
Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет взаимовыгодное решение в конфликтах.
Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
_FR>...Но опять же: а этого ли ждут при приёме на работу?
_FR>Например я для себя определяю "командность" работы как...
_FR>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Как человек, часто спрашивающий при приеме на работу об опыте команжной разработки, могу сообщить информацию, которая может оказаться полезной. Когда вам задают такой вопрос, в ответ полагается делать одно из двух:
1) Просто сказать "да" и привести пример проекта, указав количество разработчиков и вашу роль в нем.
2) Просто сказать "нет", и не трахать людям мозг.
Все остальные варианты ответов нормальный человек в контексте собеседования расценит как поыптку выноса мозга, и, что самое интересное — как симптом непригодности кандидата к командной работе. Ибо, в таком случае кандидат своим поведением наглядно демонстрирует, что
1) Он не понимает простых вещей.
2) Не в состоянии дать простого ответа на прямо поставленный вопрос.
Что уже делает командную работу с ним совершенно невозможной.
Подробно.
Когда при приеме на работу спрашивают об опыте командной разработки, спрашиващего, если он не пионер или идиот (что бывает не так часто, как может показаться), обычно интересует очень простая штука:
Вы когда-нибудь работали хоть над одним проектом в группе с другими программистами? Таким образом, что надо было как-то договариваться с ним, чтобы ее, работу, сделать? Или всегда работали в одно жало?
Также собеседующему интересна и косвенно связанная с основным вопросом тема — со средствами обеспечения групповой разработки опыт работы у вас есть? Зачем нужна система контроля версий — понятно? Зачем багтрекер нужен — понятно? Зачем нужны разные правила, ограничивающие вашу свободу, вроде код-стандартов или правил работы с репозиторием — понятно?
Ясен пень, что вы скажете "понятно-понятно" в любом случае, знаете все тулы, какие-не назови, и прочее, прочее. Поэтому вас и не спрашивают, понятно вам что-то или нет. Вас спрашивают о другом — опыт командной разработки у вас был?
Если был, то у вас была возможность осознать проблемы командной разработки, и объяснять, "зачем" все вышеперечисленное надо, преодолевая ваше сопротивление, с высокой вероятностью не придется. А вот если не было, то скорее всего придется, независимо от того, что вы знаете, и каким определением "командной работы" пользуетесь.
