Комментарии 26
Конечно, вы можете разговаривать сами с собой, но если это происходит слишком часто, вам также нужна медицинская помощь.Всё, ушел в больничку. Всегда при возникновении какой-либо проблемы обговариваю её сам с собой. Так решение находится быстрее.
Вообще цель — это минимум общенияС этим не согласен. Общение должно быть, и его должно быть много. Естественно не постоянно трещать о «левых» темах.
Мой взгляд на данную тематику — Я работаю один потому что:
— Постоянно решая многочисленные проблемы в одиночку Я невероятно быстро учусь. И последующее возникновение подобных проблем меня не пугает.
— Я отчитываюсь только перед собой и управляю моими действиями только Я, ну, может ещё жена… чуть-чуть.
— Нет конфликтных вопросов относительно реализации.
— Тестирование и оценка производится сторонними людьми и женой — результаты тестов гораздо объективней оценки товарищами по команде.
— Проблемы помогают решать не товарищи по команде, которые знают о проблеме не больше чем ты сам, а десятки людей на авторитетных форумах.
— Страсть обеспечивается желанием, заработать денег на квартиру, а так же попутными желаниями жены.
и самое главное…
— Все деньги от реализации проекта достаются мне, ну, и чуть-чуть жене.
— Постоянно решая многочисленные проблемы в одиночку Я невероятно быстро учусь. И последующее возникновение подобных проблем меня не пугает.
— Я отчитываюсь только перед собой и управляю моими действиями только Я, ну, может ещё жена… чуть-чуть.
— Нет конфликтных вопросов относительно реализации.
— Тестирование и оценка производится сторонними людьми и женой — результаты тестов гораздо объективней оценки товарищами по команде.
— Проблемы помогают решать не товарищи по команде, которые знают о проблеме не больше чем ты сам, а десятки людей на авторитетных форумах.
— Страсть обеспечивается желанием, заработать денег на квартиру, а так же попутными желаниями жены.
и самое главное…
— Все деньги от реализации проекта достаются мне, ну, и чуть-чуть жене.
В одиночку учиться очень сложно, поскольку придется затратить кучу времени на неправильные пути решения, в то время, как кто-то более опытный может сразу направить в верную сторону.
Хороший поинт. Но надо попасть в команду, где люди любят учить других людей. А еще лучше если там практикуется (хотя бы частично) парное программирование.
Может быть сложно и бывает долго, зато надёжно. Раз на швабру наступишь, уже будешь аккуратней. А так когда тебе подсказывают где очередная швабра, это расслабляет. Замыкаться конечно не стоит, но всё же упор я бы делал на самообразование.
Соглашусь с автором выше — общение должно быть. Разработка какого-то функционала должно обсуждаться. Митинги нужны, что бы так же выделить новые направления разработки.
Что же касается статус-репортов, то их многие не любят — это факт. Но их можно избежать с введением системы управлением проектами, что мы менеджеры видели работу и отчитывались выше при этом не беспокоя рабочий процесс и программистов.
Что же касается статус-репортов, то их многие не любят — это факт. Но их можно избежать с введением системы управлением проектами, что мы менеджеры видели работу и отчитывались выше при этом не беспокоя рабочий процесс и программистов.
Видимо, надо пояснить.
Минимум общения — значит минимум оверхеда.
Конечно общение должно быть. Но надо очень аккуратно выбирать митинги и оценивать их целесообразность.
И конечно, если есть сомнения в решении проблемы, надо их обсудить с кем-то.
И конечно, если есть новые идеи, их тоже надо обсудить.
Но. Не надо прибегать к товарищу, вырывать его из состояния потока, и рассказывать новую гениальную идею.
Не надо также прибегать и сразу задавать вопрос, ответ на который знает гугл.
И еще много чего не надо делать.
Общение общению рознь.
Минимум общения — значит минимум оверхеда.
Конечно общение должно быть. Но надо очень аккуратно выбирать митинги и оценивать их целесообразность.
И конечно, если есть сомнения в решении проблемы, надо их обсудить с кем-то.
И конечно, если есть новые идеи, их тоже надо обсудить.
Но. Не надо прибегать к товарищу, вырывать его из состояния потока, и рассказывать новую гениальную идею.
Не надо также прибегать и сразу задавать вопрос, ответ на который знает гугл.
И еще много чего не надо делать.
Общение общению рознь.
В целом всё правильно в статье. Но мне кажется, что главная проблема команд заключается в другом. Со слов ДеМарко, командой неверно называть группу людей, работающих над одной задачей или одним проектом, и я согласен. Команда это что-то большее. Так вот проблема в том, что команду нельзя построить «извне». Для этого нет рецепта. Более или менее известны условия, в которых появляются команды и рецепты для «убийства» команды.
Команда — тема болезненная. Для меня, например.
Расскажите, почему?
Много надежды полагал на работу в команде. Опыт у меня пока небольшой, но основные проблемы, с которыми пришлось столкнуться — «культ Карго*» (по Макконнеллу) и банальное отсутствие интереса. Наименее я был в восторге от частых и затянутых собраний, которые проводились с целью «стимулирования команды», но на деле никакой полезной нагрузки не несли.
Но ведь негативный опыт тоже опыт. Теперь осознаю роль менеджмента и важность управления процессом разработки. Наверное, потому и стал интересоваться Agile после этого. :)
* «Культ Карго». Цитата из «Code Complete»:
Но ведь негативный опыт тоже опыт. Теперь осознаю роль менеджмента и важность управления процессом разработки. Наверное, потому и стал интересоваться Agile после этого. :)
* «Культ Карго». Цитата из «Code Complete»:
На первый взгляд эти два типа самозванцев противоположны друг другу. Первые страшно бюрократизированы, вторые олицетворяют собой хаос. Однако есть одна общая ключевая черта, которая на самом деле важнее, чем все их различия. Ни те, ни другие не могут быть эффективны, потому что ни те, ни другие не понимают, что же действительно делает проект успешным. Они стараются имитировать действия, чтобы быть похожими на эффективные фирмы, исповедующие тот же стиль. Но поскольку они не понимают причин эффективности методов, то втыкают бамбуковые палочки в уши и надеются на удачное приземление самолета. Многие проекты в таких фирмах проваливаются, потому что это просто две различные вариации культа карго» в разработке ПО, похожие в своем непонимании причин успеха. Культ карго» в разработке ПО легко узнаваем. Инженеры программисты, приверженцы этого культа, оправдывают свои методы работы словами мы всегда так работаем» или стандарты работы нашей компании требуют, чтобы мы работали так», даже если конкретные приемы просто бессмысленны. Они отказываются признать наличие компромиссов обоих.
>Меньше совещаний. Любое совещание, которое не решает конкретную проблему, должно быть отменено. К примеру, статус-репорт митинги — это совершенно идиотская практика.
Полностью с вами согласен! Но вот некоторые адепты Agile практик будут явно не в восторге.
Полностью с вами согласен! Но вот некоторые адепты Agile практик будут явно не в восторге.
Надо не забывать что эффективная команда не возможна без сильного руководителя. А то получится как в басне лебедь рак и щука. Из этого и личного опыта есть еще один вывод, не советаю брать друзей в команду. Интересно услыщать мнение тех укого в команеде не один и не два человека…
Кстати, на эту тему. Частенько говорят, что команда должна быть self-organized. Особенно на это делают упор в Scrum. Я уверен, самоорганизация невозможно без хорошего лидера. Команда середнячков, конечно, тоже самоорганизуется, но она скорее будет делать упор на выживание, чем на достижения высоких целей. Так что нужен лидер и хотя бы пару сильных духом и скилом людей.
> Команда середнячков, конечно, тоже самоорганизуется, но она скорее будет делать упор на выживание, чем на достижения высоких целей.
С этим почти согласен, а с остальным в комментарии — нет. Лидер, это конечно, круто и полезно, но их крайне мало, как показывает практика. Команды просто вынуждены самоорганизовываться. А упора на выживание оказывается достаточно для многих проектов. В конце концов, не все пишут ПО для космических кораблей или превосходный стартап строят. Ну и вообще, словосочетание «высокие цели» можно понимать сильно по-разному.
У нас, например, микрокоманда: два «с половиной» человека. И ничего. Мы — два разработчика — не даём менеджеру (не включаю его в команду), поломать проект. (Наш менеджер очень хорошо умеет «продать» продукт, но, к сожалению, не смыслит в том, как его надо разрабатывать.) При всём при этом, я не могу назвать себя и коллегу великолепными управленцами или выделить среди нас лидера.
С этим почти согласен, а с остальным в комментарии — нет. Лидер, это конечно, круто и полезно, но их крайне мало, как показывает практика. Команды просто вынуждены самоорганизовываться. А упора на выживание оказывается достаточно для многих проектов. В конце концов, не все пишут ПО для космических кораблей или превосходный стартап строят. Ну и вообще, словосочетание «высокие цели» можно понимать сильно по-разному.
У нас, например, микрокоманда: два «с половиной» человека. И ничего. Мы — два разработчика — не даём менеджеру (не включаю его в команду), поломать проект. (Наш менеджер очень хорошо умеет «продать» продукт, но, к сожалению, не смыслит в том, как его надо разрабатывать.) При всём при этом, я не могу назвать себя и коллегу великолепными управленцами или выделить среди нас лидера.
Я бы добавил, что руководитель может быть ситуационный. В зависимости от ситуации и проблем, стоящих перед командой, у нас руководитель может меняться. Постоянным остается только право сказать «Ша всем, делаем так!» у наше самого доброго, но используется оно только в случаях явного тупика или отсутствия согласия в конкретной ситуации. А так, вполне себе анархия.
В команде 14 человек, работаем вместе 9 лет. Дружим семьями (ну почти все).
В команде 14 человек, работаем вместе 9 лет. Дружим семьями (ну почти все).
Мне кажется, в построении команды применим подход «Добавляй людей в команду, только если не можешь не добавить». Иначе в итоге получается, что тратишь время:
Т.е. больше времени уходит на разъяснения.
- на то, чтобы придумать, какое задание дать человеку
- на формальное описание, того что нужно сделать
- на проверку сделанного
Т.е. больше времени уходит на разъяснения.
Статья ни о чем.
Эффективная команда = Креативные люди + Мотивация
Все остальное, что Вы написали — херь.
douglasernstylp.files.wordpress.com/2010/10/office_space.jpg
Все остальное, что Вы написали — херь.
douglasernstylp.files.wordpress.com/2010/10/office_space.jpg
Не думаю, что твое утверждение каким-то образом противоречит статье, но безусловно является не полным.
Вот соберешь ты команду креативных, мотивированных студентов, которые не умеют программировать.
И че? За год сделаешь новый фейсбук?
Вот соберешь ты команду креативных, мотивированных студентов, которые не умеют программировать.
И че? За год сделаешь новый фейсбук?
Адекватность, желание учиться и минимальные навыки — требования по дефолту, посему не обсуждаются. Опыт приходит во время.
P.S. Цукерман сделал фейсбук, будучи студентом, и неумея программировать. Сделал по книжке для чайников. Дуров тоже осваивал php, пока писал вконтакт, стянув идею и дизайн у Цукермана.
P.S. Цукерман сделал фейсбук, будучи студентом, и неумея программировать. Сделал по книжке для чайников. Дуров тоже осваивал php, пока писал вконтакт, стянув идею и дизайн у Цукермана.
Яндекс, Гугл, Эйпл это подтверждают. Один спец в поле воин сам с собой.
Что касается Цукерберга, так он просто не боялся экспериментировать и вовремя создал то, что давно люди ждали.
Что касается Цукерберга, так он просто не боялся экспериментировать и вовремя создал то, что давно люди ждали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффективная команда