Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
_FR>...Но опять же: а этого ли ждут при приёме на работу?
_FR>Например я для себя определяю "командность" работы как...
_FR>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Как человек, часто спрашивающий при приеме на работу об опыте команжной разработки, могу сообщить информацию, которая может оказаться полезной. Когда вам задают такой вопрос, в ответ полагается делать одно из двух:
1) Просто сказать "да" и привести пример проекта, указав количество разработчиков и вашу роль в нем.
2) Просто сказать "нет", и не трахать людям мозг.
Все остальные варианты ответов нормальный человек в контексте собеседования расценит как поыптку выноса мозга, и, что самое интересное — как симптом непригодности кандидата к командной работе. Ибо, в таком случае кандидат своим поведением наглядно демонстрирует, что
1) Он не понимает простых вещей.
2) Не в состоянии дать простого ответа на прямо поставленный вопрос.
Что уже делает командную работу с ним совершенно невозможной.
Подробно.
Когда при приеме на работу спрашивают об опыте командной разработки, спрашиващего, если он не пионер или идиот (что бывает не так часто, как может показаться), обычно интересует очень простая штука:
Вы когда-нибудь работали хоть над одним проектом в группе с другими программистами? Таким образом, что надо было как-то договариваться с ним, чтобы ее, работу, сделать? Или всегда работали в одно жало?
Также собеседующему интересна и косвенно связанная с основным вопросом тема — со средствами обеспечения групповой разработки опыт работы у вас есть? Зачем нужна система контроля версий — понятно? Зачем багтрекер нужен — понятно? Зачем нужны разные правила, ограничивающие вашу свободу, вроде код-стандартов или правил работы с репозиторием — понятно?
Ясен пень, что вы скажете "понятно-понятно" в любом случае, знаете все тулы, какие-не назови, и прочее, прочее. Поэтому вас и не спрашивают, понятно вам что-то или нет. Вас спрашивают о другом — опыт командной разработки у вас был?
Если был, то у вас была возможность осознать проблемы командной разработки, и объяснять, "зачем" все вышеперечисленное надо, преодолевая ваше сопротивление, с высокой вероятностью не придется. А вот если не было, то скорее всего придется, независимо от того, что вы знаете, и каким определением "командной работы" пользуетесь.
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
Не претендую на лучшее опредедение, но у меня такое (по мотивам Jim McCarthy):
Теам = состояние группы при котором
0. Состоящие в ней имеют "shared vision".
1. Достоинства участвующих складываются а недостатки нивелируются.
Здравствуйте, _FRED_, Вы писали:
_FR>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
Здравствуйте, _FRED_, Вы писали:
_FR>Отсюда и любопытство: что вы называете "командной работой"?
Характеристики команды
ясность общих ценностей и целей,
доверие, взаимный контроль, взаимопомощь и взаимозаменяемость,
коллективная ответственность за результаты труда,
самоорганизация и самоуправление,
всемерное развитие и использование индивидуального и группового потенциалов.
Группа vs. команда
Цель
Гр. Ставиться узкая задача, общие цели не проясняются.
К. Ясные, принятие всеми цели и стратегия их достижения.
Участие в работе
Гр. Выполнение должностных инструкций и распоряжений.
К. Активная позиция, нацеленность на результат, личная ответственность.
Ролевая структура
Гр. Строгое распределение ролей, должностей, обязанностей.
К. Разделение компетенций. Гибкая структура. Ротация ролей.
Руководство
Гр. Администрирование, наличие формального лидера-начальника.
К. Лидерство на основе компетентности и доверия, наставничество, помощь и поддержка.
Принятие решений
Гр. В основном приказы, и решения принятые большинством.
К. Эффективные процедуры принятия решений на основе доверия и взаимовыгоды.
Конфликты
Гр. Замалчивание, сокрытие, игнорирование.
К. Признание, интеллектуальная конкуренция, эффективное разрешение: «мы по одну сторону баррикады, а проблема – с другой».
Взаимодействие
Гр. Закрытость, избегание критики, принцип «не высовываться».
К. Доверие, свобода, проявление инициативы.
Коммуникация
Гр. Через формального лидера служебная переписка.
К. Открытость. Уверенность друг в друге и взаимное уважение.
Творчество
Гр. Стереотипность, работа по правилам.
К. Гибкость и адаптивность. Непрерывное совершенствование и рост компетенций. Раскрытие творческого потенциала каждого.
Пример
Гр. Гребцы на байдарке на гребном канале.
К. Команда туристов-водников, которые сплавляются по горной реке.
Командный игрок
Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело.
Постоянно приобретет новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег.
Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги.
Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению.
Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет взаимовыгодное решение в конфликтах.
Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, _FRED_, Вы писали:
_FR>>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
L>
L>Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
L>По-моему, неплохо "расписано".
на практике обычно имеется в виду все таки то, что перечислил я
OS>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы OS>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля OS>версий, багтрекинга, формализации требований).
OS>Задача интегрирования нового разработчика в комманду — на 100% задача OS>руководства комманды. А опыт коммандной работы — это вообще ни о чем.
этот вопрос — способ отсева "начинающих звезд" в команду со средненьким менеджером, где нужны середнячки программисты
"начинающие звезды" начинают на нем либо нервничать, либо понимают, что им там нечего делатьи уходят, либо же дают такое развернутое описание методологий и особенностей командной работы, что нервничать начинает работодатель и в итоге также их отсеивает
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, ___Avatar___, Вы писали:
L>>>По-моему, неплохо "расписано".
___>>на практике обычно имеется в виду все таки то, что перечислил я
L>Я так не считаю.
вы можете так не считать наблюдая и управляя рабочим процессом
но в ситуации, когда надо отвечать на этот вопрос на интервью, обычно имеется в виду все таки мой вариант
конечно возможна командная работа без всего описанного мною, но на интервью о такой работе говорить лучше не надо
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, Sanik, Вы писали:
S>>Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением. S>>Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять. S>>Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны. S>>Ну а термин из в) о "взаимном тестировании" — вообще песня
S>>Тут достаточно развернутое определение и немножко информации
___>есть идейное определение, аесть практическая реализация этого определения ___>в профессии программиста практической реализацией является именно то, что я описал ___>то что дали вы и ллойд — это идейные общие определения, подходящие для ЛЮБОЙ профессии
Я хотел бы предложить другую версию. Перечисленное ___Avatar___ — это не практическая
реализация, а набор инструментов/методологий обычно сопутствующих успешной командной работе.
Очень часто номинально команда есть, а работает вяло. Что за этим скрыто? Не вдаваясь в
долгие рассуждения, причины примерно такие:
Бестолковое управление ресурсами.
Например, начали проект без QA,
— Нафиг программистам багтрекер? Они прекрасно друг другу словами всё расскажут. И так
сойдет!
Позже решают нанять QA, и начинается креативная свистопляска по созданию велосипедов
для управления дефектами:
— Ты пошли мне письмо, когда закончишь. Тест-кейз приаттачить не забудь. И тут вот еще
в экселе добавь строчку с описанием. Ну и в аську стукнись, что письмо послал.
Такая рутина быстро начинает злить. Изменить же устоявшееся положение
дел, начав использовать инструменты, трудно как минимум по двум причинам:
1) уже образовалась привычка, 2) нехватка времени.
Другой пример, о разделении зон ответственности:
— Зачем нам разных людей на server-side и GUI? И там и там джава (заменить по вкусу).
Очевидно, что они одинаково программируются. Бестолковое управление процессами.
Примеры:
1) Code review вживую, на специально организованном митинге; пусть автор помучается,
запоминая все комментарии; зато начальнику нравится — можно ведь на час притворится
занятым, посидев на этом митинге с умным лицом и ценными замечаниями;
2) На старте большого проекта:
— Для чего вам при интеграции с системой X архитектор-то? Как начнете с ними
интегрироваться, так и разберётесь что к чему. Всегда так делали.
Где-то в середине:
— Елки, опять у X некому клиентское API обновить. Придётся самим писать, хотя
и не планировали. А это чего за новые теги в XML ответа??? Они что там, в X, с ума посходили?!
3)
— Мы уделяем значительную часть времени написанию юнит-тестов! Забота о качестве
продукта — наша гордость!
— Но ведь у нас нет continuous integration?!
— Ничего. Люди прекрасно помнят, что нужно выполнять юнит-тесты вручную. Лень, как следствие первых двух
— Тебе чего, делать больше нечего, subversion на нас троих поднимать? Прекрасно все
на шаре сохранится. Вон, никто ж больше не напрягается. Да и начальнику пофиг.
Или так:
— Да зачем нам компонентная архитектура? Все прекрасно в один класс умещается. Потом
перепишем. Юнит-тесты? Да ну их, только время тратить — всё ж работает.
Список, конечно же, неполный, но вырисовывается одна мысль — командная работа возникает
тогда, когда для достижения общей цели каждый участник команды, включая менеджера,
стремится эффективно выполнять свою часть так, чтобы увеличить эффективность остальных.
Эффективность — многокритериальна. Тут и затраченное время, и сложность понимания реализации,
и количество дефектов, отловленных тестами, и возможность переиспользования кода и много
чего еще. Правильно подобранные инструменты же помогают достичь максимального количества
критериев с минимальными затратами.
> Часто при приёме на работу спрашивают об опыте "командной разработки". > Мне вот очень интересно: что под этим понимается? Хотелось бы узнать > короткое, ёмкое, но точное и максимально полное определение. > > Например, является ли "командной разработкой" всего лишь "совместная > работа трёх и более человек"? Мне кажется, не любую работу "трёх и > более" человек можно назвать "командной" > > Может быть, "командная" — это такая работа, при которой несколько > человек вместе работают эффективнее, чем по отдельности? Но и здесь не > ясно — в компании из трёх сотрудников (директора, бухгалтера и > программиста) получается тоже "командная" разработка? На мой взгляд, это > определение похоже на правду, но сомневаюсь, что требования в вакансиях > подразумевают именно такой вид "командной работы" > > Или же "командная работа" — это "организованный по одной из [описанных в > соответствующей литературе] методик процесс производства"? В таком > случае, как я понимаю, в "команде" может быть лишь один программист > (вкупе с проектировщиком, тестировщиком, аналитиком и прочими). Но опять > же: а этого ли ждут при приёме на работу? > > Например я для себя определяю "командность" работы как непрерывные > коммуникации (даже "постоянное общенгие") между сотрудниками > относительно путей решения существующих задач, обсуждения применяемых > технологий, обмена опытом и знаниями. Но, получается, что командной > разработкой могут заниматься и два формально не организованных человека, > находящихся на разных континентах и общающихся между собой через интернет… > > Отсюда и любопытство: что вы называете "командной работой"? С "наукой" > по данному вопросу я не знаком, потому буду особенно благодарен и за > ссылки на авторитетные источники по данному вопросу. > Что делает одежда с человеком! Просто чудеса какие-то творит. Никто, > ничто и звать никак, а шляпу надел и личность.
Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы
не добавляет абсолютно никакого скила. (Конечно помимо систем контроля
версий, багтрекинга, формализации требований).
Задача интегрирования нового разработчика в комманду — на 100% задача
руководства комманды. А опыт коммандной работы — это вообще ни о чем.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, bl-blx, Вы писали:
BB>>…но вырисовывается одна мысль — командная работа возникает BB>>тогда, когда для достижения общей цели каждый участник команды, включая менеджера, BB>>стремится эффективно выполнять свою часть так, чтобы увеличить эффективность остальных.
_FR>Здорово сказано
_FR>Но что является критерием эффективности? Количество багов? Сумма заработанных денег? Скорость реализации фич? С любым вышеперечисленным можно переврать Не может ли таковым критерием служить персональное мнение менеджера aka тимлида?
А нету одного единственно верного критерия.
В зависимости от взгляда критерии могут быть разными.
Для фирмы в целом это вполне может быть и сумма заработанных денег.
Для команды разработчиков — попадание в бюджет и сроки...
Всяких разных метрик много и в зависимости от того, что для тебя важно,
можешь подобрать свои критерии.
Здравствуйте, Other Sam, Вы писали:
OS>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы OS>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля OS>версий, багтрекинга, формализации требований).
Узко мыслишь.
А как же "communication skills" и связанные с ними вещи?
Работая в команде тебе как минимум придется:
— внятно объяснять и аргументировать свои решения, идеи и пр... другим
— выслушивать, понимать и принимать аргументы других
— критиковать самому и выслушивать критику других
— подстараиваться под других
— учитывать при планировании/разработке своей части вклад других (только не говори, что все за тебя сделает манагер)
Если кто-то слишком долго работал в одиночку, то все эти особенности
работы с другими могут свести на нет супер-пупер технические скиллы.
Если он не научится работать в команде,
то надежда такого гения будет только в том, что ради него одного нагнут всех остальных
Здравствуйте, _FRED_, Вы писали:
_FR>>>а то, как именно должны быть построены взаимоотношения в команде не важно.
L>>Не всегда можно эти взаимоотношения построить, от людей сильно зависит, являются ли они командными игроками или нет.
_FR>Это понятно.
_FR>Просто при таком определении "командности" получается, что в команде должен быть один человек — дерижёр или тренер (раз уж в самой википедии сослались на Бейба) и результат работы команды зависит именно от него. И не зависит от члена команды. Простой участник может или "вписаться" или нет (что решает [должен решать] тим-лид) но не может отвечать за результат работы команды в целом и даже за собственный, потому что собственный результат часто может зависеть от работы других участников команды, которая так же регулируется тим-лидом. Правильно я рассуждаю?
Ты в детстве в футбол что-ли ни разу не играл? Вот тебе пример командной работы, когда никакого тим-лида нет.
_FR>А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
С "целиком и полностью" — не согласен. Если человек не хочет работать в комманде, то никакой самый расчудесный руководитель не спасет.
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
а) наличие системы контроля версий и более менее "общего" кода
б) использование терминологии паттернов проектирования в качестве внутреннего языка общения вместо "а я вот такую фигню сделал, она одной хрень вот сюда тырится, а вот этими тремя коннектиться туда, сюда и на сервис на соседней тачке"
в) взаимное тестирование, ну и в идеале, взаимный код ревью
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, _FRED_, Вы писали:
_FR>>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
___>а) наличие системы контроля версий и более менее "общего" кода ___>б) использование терминологии паттернов проектирования в качестве внутреннего языка общения вместо "а я вот такую фигню сделал, она одной хрень вот сюда тырится, а вот этими тремя коннектиться туда, сюда и на сервис на соседней тачке" ___>в) взаимное тестирование, ну и в идеале, взаимный код ревью
г) еще бактрекер и общую регулярно обновляемую документацию можно добавить в список
Здравствуйте, Sanik, Вы писали:
S>Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением. S>Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять. S>Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны. S>Ну а термин из в) о "взаимном тестировании" — вообще песня
S>Тут достаточно развернутое определение и немножко информации
есть идейное определение, аесть практическая реализация этого определения
в профессии программиста практической реализацией является именно то, что я описал
то что дали вы и ллойд — это идейные общие определения, подходящие для ЛЮБОЙ профессии
OS>>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы OS>>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля OS>>версий, багтрекинга, формализации требований).
OS>>Задача интегрирования нового разработчика в комманду — на 100% задача OS>>руководства комманды. А опыт коммандной работы — это вообще ни о чем.
___>этот вопрос — способ отсева "начинающих звезд" в команду со средненьким менеджером, где нужны середнячки программисты
___>"начинающие звезды" начинают на нем либо нервничать, либо понимают, что им там нечего делатьи уходят, либо же дают такое развернутое описание методологий и особенностей командной работы, что нервничать начинает работодатель и в итоге также их отсеивает
Послушайте, вы уже столько раз акцентировали на себе внимание, что имеено ваши определния верны, что начинает казаться что вы и есть "начинающая звезда"
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
Мне на ум сразу приходит несколько основных пунктов:
1) Направленная и эффективная работа каждого члена команды на достижение общего результата.
2) Умение нормально общаться в команде, находить общий язык, объяснять свою точку зрения, слушать других, находить компромиссы в решениях.
3) Опыт работы с процессами, характерными для командной разработки — например многопользовательская работа с системой контроля версий, умение правильно распределять и распараллеливать задачи между программистами, или наоборот, слушать и выполнять то, что говорит ведущий программист, следовать общим конвенциям и правилам при разработке, выработка общего языка и видения продукта, оформление кода и документации так, чтобы это было понятно и удобно для других членов команды и т.д.
Re[3]: Что такое "командная работа"?
От:
Аноним
Дата:
08.01.10 19:14
Оценка:
Здравствуйте, ___Avatar___, Вы писали:
___>г) еще бактрекер и общую регулярно обновляемую документацию можно добавить в список
Ага...
А еще подключение компов к сети и наличие наличия ___Avatar___'а за соседним столом
Здравствуйте, _FRED_, Вы писали:
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
.... _FR>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Попробую и я дать свое определение:
Командной работой называется одновременная работа нескольких человек над общей задачей (задачами), включающая общение между участниками и использование ими результатов работы друг друга.
Всякие процессы и тулзы типа SVN, трекеров багов и запросов — это инструменты, облегчающие командную работу при их правильном применении, и не более того.
А вот что такое команда и чем определяется ее качество — это я здесь написать не возьмусь, ибо есть миллион определений и все правильные. Ключевое слово — синергетический эффект.
Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
Например, является ли "командной разработкой" всего лишь "совместная работа трёх и более человек"? Мне кажется, не любую работу "трёх и более" человек можно назвать "командной"
Может быть, "командная" — это такая работа, при которой несколько человек вместе работают эффективнее, чем по отдельности? Но и здесь не ясно — в компании из трёх сотрудников (директора, бухгалтера и программиста) получается тоже "командная" разработка? На мой взгляд, это определение похоже на правду, но сомневаюсь, что требования в вакансиях подразумевают именно такой вид "командной работы"
Или же "командная работа" — это "организованный по одной из [описанных в соответствующей литературе] методик процесс производства"? В таком случае, как я понимаю, в "команде" может быть лишь один программист (вкупе с проектировщиком, тестировщиком, аналитиком и прочими). Но опять же: а этого ли ждут при приёме на работу?
Например я для себя определяю "командность" работы как непрерывные коммуникации (даже "постоянное общенгие") между сотрудниками относительно путей решения существующих задач, обсуждения применяемых технологий, обмена опытом и знаниями. Но, получается, что командной разработкой могут заниматься и два формально не организованных человека, находящихся на разных континентах и общающихся между собой через интернет…
Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Lloyd, Вы писали:
_FR>>Отсюда и любопытство: что вы называете "командной работой"? С "наукой" по данному вопросу я не знаком, потому буду особенно благодарен и за ссылки на авторитетные источники по данному вопросу.
L>Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
L>По-моему, неплохо "расписано".
Да, хорошо; но на сколько я понимаю данную формулировку, она означает, что конкретная организация работы (производства) в каждом случае (для каждой команды) должна (или может) быть разной, в зависимости от индивидуальных особенностей участников команды. Важна лишь цель организации труда — получение максимальной эффективности от каждого сотрудника, а то, как именно должны быть построены взаимоотношения в команде не важно.
Я прав в своей оценке?
Help will always be given at Hogwarts to those who ask for it.
L>>Teamwork is a joint action by two or more people, in which each person contributes with different skills and express his or her individual interests and opinions to the unity and efficiency of the group in order to achieve common goals. This does not mean that the individual is no longer important; however, it does mean that effective and efficient teamwork goes beyond individual accomplishments. The most effective teamwork is produced when all the individuals involved harmonize their contributions and work towards a common goal.
L>>По-моему, неплохо "расписано".
_FR>Да, хорошо; но на сколько я понимаю данную формулировку, она означает, что конкретная организация работы (производства) в каждом случае (для каждой команды) должна (или может) быть разной, в зависимости от индивидуальных особенностей участников команды. Важна лишь цель организации труда — получение максимальной эффективности от каждого сотрудника,
Только не "от каждого сотрудника", а "от команды".
_FR>а то, как именно должны быть построены взаимоотношения в команде не важно.
Не всегда можно эти взаимоотношения построить, от людей сильно зависит, являются ли они командными игроками или нет.
_FR>Я прав в своей оценке?
Здравствуйте, Lloyd, Вы писали:
_FR>>Да, хорошо; но на сколько я понимаю данную формулировку, она означает, что конкретная организация работы (производства) в каждом случае (для каждой команды) должна (или может) быть разной, в зависимости от индивидуальных особенностей участников команды. Важна лишь цель организации труда — получение максимальной эффективности от каждого сотрудника, L>Только не "от каждого сотрудника", а "от команды".
Да, так точнее.
_FR>>а то, как именно должны быть построены взаимоотношения в команде не важно.
L>Не всегда можно эти взаимоотношения построить, от людей сильно зависит, являются ли они командными игроками или нет.
Это понятно.
Просто при таком определении "командности" получается, что в команде должен быть один человек — дерижёр или тренер (раз уж в самой википедии сослались на Бейба) и результат работы команды зависит именно от него. И не зависит от члена команды. Простой участник может или "вписаться" или нет (что решает [должен решать] тим-лид) но не может отвечать за результат работы команды в целом и даже за собственный, потому что собственный результат часто может зависеть от работы других участников команды, которая так же регулируется тим-лидом. Правильно я рассуждаю?
А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, ___Avatar___, Вы писали:
L>>>>По-моему, неплохо "расписано".
___>>>на практике обычно имеется в виду все таки то, что перечислил я
L>>Я так не считаю.
___>вы можете так не считать наблюдая и управляя рабочим процессом ___>но в ситуации, когда надо отвечать на этот вопрос на интервью, обычно имеется в виду все таки мой вариант
___>конечно возможна командная работа без всего описанного мною, но на интервью о такой работе говорить лучше не надо
Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением.
Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять.
Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны.
Ну а термин из в) о "взаимном тестировании" — вообще песня
Здравствуйте, ___Avatar___, Вы писали:
___>Здравствуйте, Sanik, Вы писали:
S>>Простите, конечно, но я бы сказал что переисленные Вами пункты вообще сложно назвать определением. S>>Прежде всего (судя по Вашему же реплаю на свое сообщение) Ваш список не законченный и туда всегда можно что-то добавлять. S>>Пункт б) надо заменить на "Clear communication". Шаблоны тут не обязательны. S>>Ну а термин из в) о "взаимном тестировании" — вообще песня
S>>Тут достаточно развернутое определение и немножко информации
___>есть идейное определение, аесть практическая реализация этого определения ___>в профессии программиста практической реализацией является именно то, что я описал ___>то что дали вы и ллойд — это идейные общие определения, подходящие для ЛЮБОЙ профессии
Ну что Вы. Это чисто практическое.
Ваши "паттерны проектирования" были адаптированны из строительной индустрии. Не сужайте свой кругозор.
Ибо за березой Вы можете не увидеть лес.
> OS>Это пустой трёп в описаниях вакансий. Как таковой опыт коммандной работы > OS>не добавляет абсолютно никакого скила. (Конечно помимо систем контроля > OS>версий, багтрекинга, формализации требований). > > OS>Задача интегрирования нового разработчика в комманду — на 100% задача > OS>руководства комманды. А опыт коммандной работы — это вообще ни о чем. > > этот вопрос — способ отсева "начинающих звезд" в команду со средненьким > менеджером, где нужны середнячки программисты > > "начинающие звезды" начинают на нем либо нервничать, либо понимают, что > им там нечего делатьи уходят, либо же дают такое развернутое описание > методологий и особенностей командной работы, что нервничать начинает > работодатель и в итоге также их отсеивает
Какой смысл отсеивать тех, кто не имеет опыта коммандной работы?
Я на своей первой работе научился пользоваться VSS-ом к концу второго
дня. А первый мой код, который попал в VSS появился не раньше, чем через
неделю (а может быть и через 2). До этого, я вообще не знал, что такое
система контроля версий.
Здравствуйте, Lloyd, Вы писали:
L>Ты в детстве в футбол что-ли ни разу не играл? Вот тебе пример командной работы, когда никакого тим-лида нет.
Аспекты организации "дворовых" команд меня не интересуют.
_FR>>А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
L>С "целиком и полностью" — не согласен. Если человек не хочет работать в комманде, то никакой самый расчудесный руководитель не спасет.
А если хочет? Я говорю о "хорошей" ситуации, когда руководитель имеет команду людей, которыми доволен и которые довольны руководителем и хотят работать в команде. Если кто-то не хочет — это уже не совсем команда.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, mbergal, Вы писали:
_FR>>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается? Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
M>Не претендую на лучшее опредедение, но у меня такое (по мотивам Jim McCarthy): M>Теам = состояние группы при котором
Если помнишь, в школе\институте когда на вопрос преподователя "дайте такое-то определение" учащийся начинал "это когда…" все мои преподователи от этого "начала" морщились
M>0. Состоящие в ней имеют "shared vision".
Прекрасно, это больше напоминает "самоорганизующуюся" группу, раз уж у участников должен быть "vision", правильно? Роль руководителя в том, что бы обеспечить, что бы группа "не стояла", а двигаться (куда и как) она будет сама, исходя из этого самого "vision". Правильно?
M>1. Достоинства участвующих складываются а недостатки нивелируются.
Кем "складываются"? Кто решает, что это вот достоинство и оно нам нужно, а это вот здесь лучше не надо? Руководитель? Общее партсобрание?
Общее определение вроде данного тобой скорее всего будет верным, но оно не сможет дать ответа на вопрос "за счёт чего" достигается успешность работы в команде. С обоими пунктами у тебя в общем-то понятно но опять же это недалеко от определения "дворовой футбольной команды" в которой так же есть оба названных пункта.
Кстати, о "дворовых командах": может быть тренерский штаб и прочая иерархия нужны лишь потому, что игроков в профессиональном футболе не пять-шесть-семь, а двадцать с лишним? То есть небольшая команда лучше сама себя организует, а лидер нужен только тогда, когда участников "много"?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, bl-blx, Вы писали:
BB>…но вырисовывается одна мысль — командная работа возникает BB>тогда, когда для достижения общей цели каждый участник команды, включая менеджера, BB>стремится эффективно выполнять свою часть так, чтобы увеличить эффективность остальных.
Здорово сказано
Но что является критерием эффективности? Количество багов? Сумма заработанных денег? Скорость реализации фич? С любым вышеперечисленным можно переврать Не может ли таковым критерием служить персональное мнение менеджера aka тимлида?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
L>>Ты в детстве в футбол что-ли ни разу не играл? Вот тебе пример командной работы, когда никакого тим-лида нет.
_FR>Аспекты организации "дворовых" команд меня не интересуют.
Это пример, призванный проиллюстрировать, что несостоятельность тезиса о необходимости руководителя для командной работы.
_FR>>>А веду я к тому, что при твоём определении "командной работы" (вернее, определении из вики) на собеседовании простого разработчика не должен быть важен опыт "командности" поскольку успешность данного опыта целиком и полностью определяется руководителем.
L>>С "целиком и полностью" — не согласен. Если человек не хочет работать в комманде, то никакой самый расчудесный руководитель не спасет.
_FR>А если хочет? Я говорю о "хорошей" ситуации, когда руководитель имеет команду людей, которыми доволен и которые довольны руководителем и хотят работать в команде. Если кто-то не хочет — это уже не совсем команда.
Руководитель такая же часть команды, как и остальные игроки.
Re[4]: Что такое "командная работа"?
От:
Аноним
Дата:
08.01.10 08:27
Оценка:
Здравствуйте, Other Sam, Вы писали:
OS>Какой смысл отсеивать тех, кто не имеет опыта коммандной работы?
OS>Я на своей первой работе научился пользоваться VSS-ом к концу второго OS>дня. А первый мой код, который попал в VSS появился не раньше, чем через OS>неделю (а может быть и через 2). До этого, я вообще не знал, что такое OS>система контроля версий.
Через неделю ты скорей всего только научился пользоваться основными функциями VSS.
Практически уверен, что о всех сложностях "configuration management" через неделю работы
ты даже и не догадывался...
Но научиться можно практически всему. Это всегда лишь вопрос времени.
Что касается "командной работы", то тут не все так просто.
Некоторые личностные особенности могут очень сильно затруднять работу в команде.
Скажем обидчивому и вспыльчивому человеку будет всегда сложно выслушивать критику,
даже если она объективна и по делу.
Здравствуйте, Lloyd, Вы писали:
L>>>Ты в детстве в футбол что-ли ни разу не играл? Вот тебе пример командной работы, когда никакого тим-лида нет. _FR>>Аспекты организации "дворовых" команд меня не интересуют. L>Это пример, призванный проиллюстрировать, что несостоятельность тезиса о необходимости руководителя для командной работы.
"дворовый" футбол это всё-таки не работа, а развлечение. Зачем руководитель в профессиональном футболе, если во дворе обходятся без него?
L>Руководитель такая же часть команды, как и остальные игроки.
"такая же" — это откуда посмотреть. Обязанности у него отличные от обязанностей игроков. Иначе зачем тогда нужен "руководитель"?
Если попробовать вдуматься в твои слова, то какой-то бред получается, посмотри: с одной стороны руководитель не нужен, ибо дворовые команды вполне обходятся без него. С другой: руководитель такой же член команды, как и остальные. Тогда почему в дворовой команде не может быть руководителя? Получается, может — он же неотличим от других. Но тезис-то "о необходимости руководителя" уже признан несостоятельным
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
L>>Это пример, призванный проиллюстрировать, что несостоятельность тезиса о необходимости руководителя для командной работы.
_FR>"дворовый" футбол это всё-таки не работа, а развлечение.
А есть разница?
L>>Руководитель такая же часть команды, как и остальные игроки.
_FR>"такая же" — это откуда посмотреть. Обязанности у него отличные от обязанностей игроков. Иначе зачем тогда нужен "руководитель"?
_FR>Если попробовать вдуматься в твои слова, то какой-то бред получается, посмотри: с одной стороны руководитель не нужен, ибо дворовые команды вполне обходятся без него.
Он не является необходимым условием команндной работы. Это не значит, что он не нужен.
_FR>С другой: руководитель такой же член команды, как и остальные. Тогда почему в дворовой команде не может быть руководителя? Получается, может — он же неотличим от других. Но тезис-то "о необходимости руководителя" уже признан несостоятельным
Тут вкладывается разный смысл в понятии "руководитель":
1. основное действующее лицо, а члены команды — это лишь исполнители его воли.
2. определенный набор обязанностей (общение с заказчиком, работа с требованиями, планирование работ, постановка процесса, разруливание конфликтов, админ. деятельность и т.д. и т.п.).
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, bl-blx, Вы писали:
_FR>Но что является критерием эффективности? Количество багов? Сумма заработанных денег? Скорость реализации фич? С любым вышеперечисленным можно переврать
Абсолютные величины, видимо, смысла не имеют. Предположу, что важна возможность
контролировать существенные отклонения от устойчивого КПД и соответствующие стоимости (COQ). _FR>Не может ли таковым критерием служить персональное мнение менеджера aka тимлида?
Если харизму прокачать, то может.
... > Через неделю ты скорей всего только научился пользоваться основными > функциями VSS. > Практически уверен, что о всех сложностях "configuration management" > через неделю работы > ты даже и не догадывался... > Но научиться можно практически всему. Это всегда лишь вопрос времени. > > Что касается "командной работы", то тут не все так просто. > Некоторые личностные особенности могут очень сильно затруднять работу в > команде. > Скажем обидчивому и вспыльчивому человеку будет всегда сложно > выслушивать критику, > даже если она объективна и по делу.
Повторюсь. К концу второго дня я пользовался основными функциями VSS —
доставал, обновлял, смотрел истории, знал как локать файлы и как их
коммитить. А это всё что нужно новому разработчику в комманде.
А обо всех сложностях "configuration management" ни одному новому
разработчику и не нужно знать. В общем, навыки необходимые для работы в
комманде я получил со скоростью настройки работчего компа. Пока
устанавливались некоторые компоненты, регистрировались мэйл-клиенты,
конфигурялась среда разработки, я освоил VSS, познакомился с админами,
узнал адреса всяких служебных серверов, познакомился с командой,
посмотрел на проект, узнал как его собирать... ну и все в таком же духе.
Так что нет такого специального навыка "умение работать в комманде".
Каждый кто учился хоть в каком-нибудь учебном заведении уже умеет
разделять работу (этому можно научиться например на лабах в ВУЗе). Все
такие люди уже умеют достаточно чтобы работать в комманде.
Насчет обидчивых-вспыльчивых — это забота руководства комманды. Если
какой-то разработчик выходит из себя из-за критики, это прямо указывает
на наличие какой-то зоны ответственности, без достаточных рычагов
управления. Например если одного разработчика имеют за ошибки в
функционировании некоторого модуля, но не позволяют внести исправление в
архитектуру этого модуля или какой-то части системы, чтобы избавиться от
источника ошибок. Ну и сам разработчик при этом прямолинейный человек. С
низкими дипломатическими навыками.
Здравствуйте, Lloyd, Вы писали:
L>>>Это пример, призванный проиллюстрировать, что несостоятельность тезиса о необходимости руководителя для командной работы. _FR>>"дворовый" футбол это всё-таки не работа, а развлечение.
L>А есть разница?
ИМХО, конечно есть. Пока ты играешь для удовольствия или поддержания формы — это одно. А если для зарабатывания денег — это другое. И правила в данных играх разные.
L>Он не является необходимым условием команндной работы. Это не значит, что он не нужен.
Пускай: команда с руководителем и без оного — две разные команды, живущие по разным принципам. Но те и другие всё равно команды. Мне вот непонятна сила, которая заставит нескольких (трёх и более) людей слаженно работать на протяжении долгого (от года) срока
Мне казалось, что сила эта и есть руководитель, задача которого (основная, но, возможно, не единственная) координировать работников. или, раз уж мы говорим о "команде", скажу "игроков".
Но если команда может существовать без руководителя, как ты говоришь, то как команда будет решать, в какую сторону двигаться? Как определит, что нужно менять в своём процессе, когда существующий процесс не приводит к ожидаемым результатам? Общее собрание будет проводить с голосованием? Не верю, что это не приведёт к тому, что все попросту не переругаются друг с другом.
Я в детстве в футбол не гонял, но играл в баскетбол и видел, что команда, в которой есть кому сказать, кто где должен стоять, где один из игроков по ходу корректирует действия товарищей, напоминая, что нужно вернуться в защиту и как разобрать игроков, что делать при нападении играет точно красивее и выигрывает намного чаще, чем та, в которой толпа "сильных индивидуальностей" бегает по полю, высказывая уважение друг к другу. Об этом как раз и говорится в вики. Просто несколько хороших парней "команду" не делают. Вернее, способны сделать лишь команду, которая в фаворе пока не появится хорошо организованный соперник, который может быть наголову ниже, но за счёт продуманной тактики и наигранной стратегии опережать более сильных индивидуумов.
_FR>>С другой: руководитель такой же член команды, как и остальные. Тогда почему в дворовой команде не может быть руководителя? Получается, может — он же неотличим от других. Но тезис-то "о необходимости руководителя" уже признан несостоятельным
L>Тут вкладывается разный смысл в понятии "руководитель": L>1. основное действующее лицо, а члены команды — это лишь исполнители его воли. L>2. определенный набор обязанностей (общение с заказчиком, работа с требованиями, планирование работ, постановка процесса, разруливание конфликтов, админ. деятельность и т.д. и т.п.).
Ты какого руководителя имел в виду? Говоря, что он не нужен (что без него можно) в команде? Я всегда под руководителем имел в виду первого из описанных выше.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
L>>Он не является необходимым условием команндной работы. Это не значит, что он не нужен.
_FR>Пускай: команда с руководителем и без оного — две разные команды, живущие по разным принципам. Но те и другие всё равно команды. Мне вот непонятна сила, которая заставит нескольких (трёх и более) людей слаженно работать на протяжении долгого (от года) срока
Некоторым просто нравится работать.
_FR>Мне казалось, что сила эта и есть руководитель, задача которого (основная, но, возможно, не единственная) координировать работников. или, раз уж мы говорим о "команде", скажу "игроков".
_FR>Но если команда может существовать без руководителя, как ты говоришь, то как команда будет решать, в какую сторону двигаться?
Цели — внешний по отношению к команде фактор.
_FR>Как определит, что нужно менять в своём процессе, когда существующий процесс не приводит к ожидаемым результатам? Общее собрание будет проводить с голосованием? Не верю, что это не приведёт к тому, что все попросту не переругаются друг с другом.
Можешь привести пример изменения, по поводу которого можно переругаться?
_FR>>>С другой: руководитель такой же член команды, как и остальные. Тогда почему в дворовой команде не может быть руководителя? Получается, может — он же неотличим от других. Но тезис-то "о необходимости руководителя" уже признан несостоятельным
L>>Тут вкладывается разный смысл в понятии "руководитель": L>>1. основное действующее лицо, а члены команды — это лишь исполнители его воли. L>>2. определенный набор обязанностей (общение с заказчиком, работа с требованиями, планирование работ, постановка процесса, разруливание конфликтов, админ. деятельность и т.д. и т.п.).
_FR>Ты какого руководителя имел в виду? Говоря, что он не нужен (что без него можно) в команде? Я всегда под руководителем имел в виду первого из описанных выше.
Здравствуйте, Lloyd, Вы писали:
_FR>>Мне казалось, что сила эта и есть руководитель, задача которого (основная, но, возможно, не единственная) координировать работников. или, раз уж мы говорим о "команде", скажу "игроков". _FR>>Но если команда может существовать без руководителя, как ты говоришь, то как команда будет решать, в какую сторону двигаться? L>Цели — внешний по отношению к команде фактор.
Вот ты упомянул "цели". А что ты называешь "целями"? В зависимости от ответа на этот вопрос с тобой можно согласиться или нет. Так же как и в вопросе о роли руководителя.
_FR>>Как определит, что нужно менять в своём процессе, когда существующий процесс не приводит к ожидаемым результатам? Общее собрание будет проводить с голосованием? Не верю, что это не приведёт к тому, что все попросту не переругаются друг с другом.
L>Можешь привести пример изменения, по поводу которого можно переругаться?
Сколько угодно: Code Style, какой DI фреймворк использовать и нужен ли он вообще, какой ORM использовать и нужен ли он вообще. Что касается дворовых команд (да и проффесиональных тоже) поводов ещё больше — кто кому должен был отдать пас и когда. Кто должен возвращаться в защиту, а кто нет. Поводов бесконечное количество.
_FR>>>>С другой: руководитель такой же член команды, как и остальные. Тогда почему в дворовой команде не может быть руководителя? Получается, может — он же неотличим от других. Но тезис-то "о необходимости руководителя" уже признан несостоятельным L>>>Тут вкладывается разный смысл в понятии "руководитель": L>>>1. основное действующее лицо, а члены команды — это лишь исполнители его воли. L>>>2. определенный набор обязанностей (общение с заказчиком, работа с требованиями, планирование работ, постановка процесса, разруливание конфликтов, админ. деятельность и т.д. и т.п.). _FR>>Ты какого руководителя имел в виду? Говоря, что он не нужен (что без него можно) в команде? Я всегда под руководителем имел в виду первого из описанных выше. L>Я имел в виду первое определение.
Тогда в чём не верны мои выводы из твоих слов?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>>>Но если команда может существовать без руководителя, как ты говоришь, то как команда будет решать, в какую сторону двигаться? L>>Цели — внешний по отношению к команде фактор.
_FR>Вот ты упомянул "цели". А что ты называешь "целями"? В зависимости от ответа на этот вопрос с тобой можно согласиться или нет. Так же как и в вопросе о роли руководителя.
Цель команды — реализация проекта при заданных ограничениях.
_FR>>>Как определит, что нужно менять в своём процессе, когда существующий процесс не приводит к ожидаемым результатам? Общее собрание будет проводить с голосованием? Не верю, что это не приведёт к тому, что все попросту не переругаются друг с другом.
L>>Можешь привести пример изменения, по поводу которого можно переругаться?
_FR>Сколько угодно: Code Style, какой DI фреймворк использовать и нужен ли он вообще, какой ORM использовать и нужен ли он вообще.
Code Style: любой адекватный программер понимает, что сами правила не важны, важно их наличие.
ORM: зачастую определяется внешними факторами (использовать mainstream-технологии, наличие купленых лицензий, ...), остальное вполне обсуждаемо. Не вижу повода для "грызни".
_FR>>>>>С другой: руководитель такой же член команды, как и остальные. Тогда почему в дворовой команде не может быть руководителя? Получается, может — он же неотличим от других. Но тезис-то "о необходимости руководителя" уже признан несостоятельным L>>>>Тут вкладывается разный смысл в понятии "руководитель": L>>>>1. основное действующее лицо, а члены команды — это лишь исполнители его воли. L>>>>2. определенный набор обязанностей (общение с заказчиком, работа с требованиями, планирование работ, постановка процесса, разруливание конфликтов, админ. деятельность и т.д. и т.п.). _FR>>>Ты какого руководителя имел в виду? Говоря, что он не нужен (что без него можно) в команде? Я всегда под руководителем имел в виду первого из описанных выше. L>>Я имел в виду первое определение.
_FR>Тогда в чём не верны мои выводы из твоих слов?
Здравствуйте, _FRED_, Вы писали:
_FR>Кстати, о "дворовых командах": может быть тренерский штаб и прочая иерархия нужны лишь потому, что игроков в профессиональном футболе не пять-шесть-семь, а двадцать с лишним? То есть небольшая команда лучше сама себя организует, а лидер нужен только тогда, когда участников "много"?
Зачастую бывает именно так, но наверное это зависит от уровня участников. Например если уровень невысокий (не сильно опытные разработчики), то лидер им нужен.
Re: Что такое "командная работа"?
От:
Аноним
Дата:
08.01.10 12:26
Оценка:
Моё понимание:
1. Открытая среда для общения и идей
2. Коллективное принятие решений на основе консенсуса по ключевым вопросам проекта
3. Синхронизация целей проекта с целями участников
4. Наличие общего видения.
Мы эту тему частичн затронули в нашем обсуждении, подкаст можешь прослушать здесь
упс, логин забыл вбить для благодарных плюсов и мотивирующих минусов
А>Моё понимание:
А>1. Открытая среда для общения и идей А>2. Коллективное принятие решений на основе консенсуса по ключевым вопросам проекта А>3. Синхронизация целей проекта с целями участников А>4. Наличие общего видения.
А>Мы эту тему частичн затронули в нашем обсуждении, подкаст можешь прослушать здесь
[...]
M>>0. Состоящие в ней имеют "shared vision".
_FR>Прекрасно, это больше напоминает "самоорганизующуюся" группу, раз уж у участников должен быть "vision", правильно? Роль руководителя в том, что бы обеспечить, что бы группа "не стояла", а двигаться (куда и как) она будет сама, исходя из этого самого "vision". Правильно?
Наверное.
M>>1. Достоинства участвующих складываются а недостатки нивелируются.
_FR>Кем "складываются"? Кто решает, что это вот достоинство и оно нам нужно, а это вот здесь лучше не надо? Руководитель? Общее партсобрание?
Оно само так получается.
_FR>Общее определение вроде данного тобой скорее всего будет верным, но оно не сможет дать ответа на вопрос "за счёт чего" достигается успешность работы в команде. С обоими пунктами у тебя в общем-то понятно но опять же это недалеко от определения "дворовой футбольной команды" в которой так же есть оба названных пункта.
Не у всякой дворовой команды есть оба названных пункта.
Я не специалист, могу лишь отослать к незаслуженно (IMHO) проигнорированной/забытой книге Jim McCarthy "Software For Your Head" и подкастам у него на сайте. Книгу лучше читать на английском (есть у mogadanez), подкасты на любителя, но мне очень понравились (и моей дочке тоже), в них интересные (иногда не очень) наблюдения и комментарии про жизнь и работу.
Здравствуйте, denis miller, Вы писали:
А>>2. Коллективное принятие решений на основе консенсуса по ключевым вопросам проекта
Увы. При таком подходе и наличии в команде хотя бы двух сильных лидеров с разными взглядами проект катится к провалу — сколько раз такое наблюдал. Есть архитектор(ы), предлагающие решения и есть ПМ, утверждающий то или иное предложение. Иначе мы получаем ситуацию в проекте, аналогичную имеющейся сейчас на Украине или в ЕС.
Искренне рад за вас, если вы действительно работаете в атмосфере Круглого стола, но король Артур все равно необходим и я уверен, он у вас есть.
Здравствуйте, nvb, Вы писали:
nvb>Попробую и я дать свое определение: nvb>Командной работой называется одновременная работа нескольких человек над общей задачей (задачами), включающая общение между участниками и использование ими результатов работы друг друга.
Сам хотел что-то подобное написать.
Принципиально то, что люди достаточно интенсивно используют результаты работы друг-друга.
Если это не так, то это не командная работа, а работа нескольких индивидуальностей над общей задачей.
Командная работа иногда позволяет делать то, что без нее не сделать нельзя. Например, большой группой накинуться на одну задачу и сделать ее за более короткий календарный срок (пусть и, возможно, за большее количество человекочасов).
Соответственно, если человек умеет хорошо работать в таком режиме, когда от него зависят другие и он зависит от кого-то, то он умеет хорошо работать командно.
Здравствуйте, MozgC, Вы писали:
_FR>>Кстати, о "дворовых командах": может быть тренерский штаб и прочая иерархия нужны лишь потому, что игроков в профессиональном футболе не пять-шесть-семь, а двадцать с лишним? То есть небольшая команда лучше сама себя организует, а лидер нужен только тогда, когда участников "много"?
MC>Зачастую бывает именно так, но наверное это зависит от уровня участников. Например если уровень невысокий (не сильно опытные разработчики), то лидер им нужен.
А если высокий, то нужен тем более.
Задача: написать принципиально новую операционку. Ресурсы: 10 человек уровня Линуса Торвальдса c равными правами + (облегчим задачу) 200 человек кодеров, тестеров, техписателей, тимлидов и прочих. Впрочем, их можно пока не нанимать — важно понимать, что они будут при необходимости.
Вы представляете себе, что там будет твориться через месяц?
_FR>Часто при приёме на работу спрашивают об опыте "командной разработки". Мне вот очень интересно: что под этим понимается?
А вы не спрашивали, что под этим понимают те кто этим интересовался ?
_FR>Хотелось бы узнать короткое, ёмкое, но точное и максимально полное определение.
Обычно что-то вроде "пастись вместе со стадом"
nvb>Искренне рад за вас, если вы действительно работаете в атмосфере Круглого стола, но король Артур все равно необходим и я уверен, он у вас есть.
Понимаю. Но не разделяю
Консенсус — критический важная штуковина. Причем это не показательная штука, что типа все "за", именно чтобы каждый в душе поддержал решение. Чтобы команда вышла на такой уровень нужно работать с командой. В Аджайл мире есть спец роль для этой цели — аджайл коуч или скрам мастер.
Ранее паттерн здесь озвучивался Проект = Команда, который помогает прийти к общему в любых вопросах. Но нужно знать как юзать это . Поэтому если команда выступает не как единный механизм, то это отразиться на реальной реализации. Если два человека не могут договориться, это означает, что хоть формально один задавит другого. Но последнее слова за реализацией. И это скрытый конфликт — и он ещё аукнеться. Поэтому круглый стол — это наше все. Да к тому же есть техники как культуру консенсуса развивать в команде.
Здравствуйте, denis miller, Вы писали:
nvb>>Искренне рад за вас, если вы действительно работаете в атмосфере Круглого стола, но король Артур все равно необходим и я уверен, он у вас есть.
DM>Понимаю. Но не разделяю
DM>Консенсус — критический важная штуковина. Причем это не показательная штука, что типа все "за", именно чтобы каждый в душе поддержал решение. Чтобы команда вышла на такой уровень нужно работать с командой. В Аджайл мире есть спец роль для этой цели — аджайл коуч или скрам мастер.
Именно. А еще можно запустить по телевизору такую серию программ, чтобы после их просмотра не было преступлений, все уступали бабушкам место в метро и не ругались матом. А сэкономленные таким образом на охране правопорядка деньги можно направить в детские дома. Но почему-то не получается...
Есть множество способов решения конфликтов. Вы говорите лишь про один вариант — интеграцию. Кроме них есть еще силовое решение, сглаживание, компромисс (это не то же, что сглаживание)... При наличии времени и соответствующих скиллов у руководителя проекта — несомненно, лучший выбор. Но если этого нет — приходится прибегать к остальным.
DM>Ранее паттерн здесь озвучивался Проект = Команда, который помогает прийти к общему в любых вопросах. Но нужно знать как юзать это . Поэтому если команда выступает не как единный механизм, то это отразиться на реальной реализации. Если два человека не могут договориться, это означает, что хоть формально один задавит другого. Но последнее слова за реализацией. И это скрытый конфликт — и он ещё аукнеться. Поэтому круглый стол — это наше все. Да к тому же есть техники как культуру консенсуса развивать в команде.
Отразится. Аукнется. Задавит. Печально. А с чего вы вообще взяли, что весь мир работает по Аджайлу? А если нет?
Вот пример. Вы работаете в организации. Она включает в себя юристов, финансистов, бухгалтеров, уборщиц, хозслужбы, айтишников. По статистике, 90% юристов свою работу не любят, я уж не говорю про остальных. То есть вы с командой проекта находитесь в некоторой ойкумене, афинском социализме, и окружающие работают на вас, вне зависимости, нравится это им или нет. Если же вы займетесь мотивацией уборщиц, то у вас не будет хватать времени на проект.
Теперь давайте эту ойкумену сузим. Предположим, есть три человека, отвечающие за архитектуру и живущие в мире друг с другом. Как в любом проекте, в нем есть несогласные, на нижнем уровне — скажем, свежеиспеченный кодер. Вам не удастся за приемлемое время объяснить кодеру-новичку, зачем нужно комментировать код — т.е. вы примените силовое решение, может быть, сославшись на правила кодирования, принятые в компании. То же самое случится, если в вашу команду придет другой человек, который работал, например, с Перфорсом, а у вас используется СВН. Опять силовое решение, опять демотивация.
Сужаем нашу ойкумену дальше. Один из архитекторов предлагает потрясающе красивое решение, но увы — оно не укладывается в бюджет заказной разработки. То есть укладывается, но за счет отказа от половины тестов. Архитектор со своей идеей так просто не расстанется — этому будет предшествовать неделя бесед, при этом оба собеседника должны быть вменяемы и один из них должен пройти через тренинг по разрешению конфликтов. Если же хотя бы одного слагаемого нет в наличии — что делать?
РМ постоянно работает с рисками. Есть риск демотивации участников и есть риск провалить проект, если все управленческие усилия и время направить на мотивацию участников. Приходится выбирать.
Я сам предпочитаю интеграцию и, если есть возможность, разрешаю конфликты именно так. Но это возможно далеко не всегда, увы.
Ибо, в таком случае кандидат своим поведением наглядно демонстрирует, что
Не верю, что это не приведёт к тому, что все попросту не переругаются друг с другом. 
