Командна робота

Як ви бачите пояснення цього терміну.

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

Але з мого досвіду все зводиться до правки багів, принаймні у нас на фірмі.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
dic0ff
>> помимо общих целей, распределения специализаций, задач есть ещё некий социально-психологический фактор, который обуславливает отношение людей, т е должны сложиться определенные дружественные отношения в коллективе. Вот тогда кучка людей (не обязательно программистов) превращается в команду
как ни неприятно это говорить, но, исходя из моего последнего опыта, необязательно иметь дружественные отношения. что необходимо, так это чувство ответственности, готовность помочь, а не пройти мимо, умение прислушиваться к другим и признавать собственные промахи...ну и осознание важности того, что ты делаешь, читай мотивированность.

а вот насчет дружеских отношений — из-за них бывает очень сложно заставить себя уйти = (

2Зануда

Знайти ніжну, люблячу жінку

работаю с командой удаленно, я — тута, они — тама. 99% тасков — саппорт, багфикс. командная работа сводится к тому, чтобы с наибольшей эффективностью и скоростью обработать входящий запрос — будь-то запрос на фикс бага, верификацию документа, код ревью т.д. Запрос передается по цепочке ответственности, эту цепочку необходимо правильно выстроить, подключить к ней нужные звенья (людей), в нужное время, в нужные места. Работа команды заключается в том, чтобы запрос поскорее нашел исполнителей и в предоставлении им собранной информации необходимой для выполнения таска — комуникэйшн пойнты, требования, доступные ресурсы, источники информации (имена код аунеров, например). Делается все в основном по почте:) — идет трэд, все больше людей к нему подключаются, вносят в него информацию и т.д. Вот вам и вся командная работа.

Для кодерків із зашкалюючим ЧСВ, навіть не знаю, яка цілі крім зеркалка, вєлік, комунікатор.

А у вас какие цели?

Коли спільна ціль лише отримувати побільше бабла, то це добре для шайки гопників.
Для кодерків із зашкалюючим ЧСВ, навіть не знаю, яка цілі крім зеркалка, вєлік, комунікатор.
Взагалі-то краще сказати, що має бути група однодумців із спільною метою.
А так, то просто робота в колективі, де є свої інтриги і понятія, яку хряки голосно називають тімворк.
При цьому добрий тімплеєр, означає, що якщо тобі щось не подобається, ти не станеш товкти колегу головою об стіну, а тихо напишеш на правильну адресу.

Думаю в плохиша краще вийде розтлумачити командну роботу.

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

Это что тут? Слет капитанов очевидностей?

аутсорс + комнадна робота = азіатський стиль

Причем тут это?
Командная работа, это когда команда работает на конечный результат, и позиция: “мой модуль работает пиzдато, а если он у соседа выедает ресурсы, то это не моя проблема” неприемлема ни для менеджмента, ни для команды.

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

Як можна мати спаяну (або споєну) команду де проектний підхід і групки програмістіврегулярну перетряхуються і ротуються.
до того ж саме керівнийтво зачасту перекрасний демотиватор, якому тре розділяти і володарювати, а не мати під боком міцін групки людей, які можуть і за себе і за коолегу постояти.

ІМНО, аутсорс + комнадна робота = азіатський стиль

Мне кажется, что правка багов конечно неизбежна, но чтобы количество этих самых багов не наводило на мысль, что это и есть «командная работа» — в команде должен быть командир. И чем толковее он будет, тем интересней будет работать в команде. А коллективные обсуждения нужны для того чтобы командиру было из чего выбрать верное решение, он ведь тоже челок.

Але з мого досвіду все зводиться до правки багів, принаймні у нас на фірмі.

У нас тоже. Вот сейчас выгребаю кучу проблем именно по этой причине. А вообще командная разработка это когда все решения и то что надо сделать обсуждается коллективно. А нету пересказывания смысла заданий через 10того человека из-за угла.

2 Питер Джеремми

Ну с таким отношением честный человек в резюме писал бы в разделе «команданая работа» что-то типа «социопат»:)

Але з мого досвіду все зводиться до правки багів, принаймні у нас на фірмі.

еще можно заниматься документированием существующего кода,
распиливанием больших и корявых классов\методов на маленькие и красивенькие (реfukторинг)

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

Командная работа — это когда группа людей работает во благо одной цели! Безусловно, это скорее всего означает, что организованное стадо отборных программистов порождает невиданное количество кода, одновременно фикся всё возрастающее количество багов, что, безусловно, демонстрирует их (программистов) высокую производительность и мотивацию, а так же повышение качества реализации проекта. При этом все выглядят довольными, с сияющими улыбками, ощущением собственной значимости в команде и радостью за проект; -)

Може бути команда з кількох людей різних спеціальностей — наприклад команда з дизайнера і програміста, і тоді «спілкування, обговорення, поради, спільне написання великих компонентів і навіть проекту» можливе, а правка багів один одного — ні:)

Підписатись на коментарі