Комментарии 65
Мне всё нравится в Agile кроме daily митингов. Если я делаю таск на 5 дней, мне ужасно впадлу идти и слушать чем кто сегодня занимался и займётся — пусть менеджер об этом думает. Я не прав? IMHO, on-demand митинги лучше всего.
Ну если митинг на 40 — 60 минут затягивается или больше… то да). Зачастую сталкивался с тем что обычно рассказывают не тем чем занимаются, а то как они реализовывают вещь которой они занимаются. Фактически можно все сказать 1- 2 предложениями, проблема например такая… Детали проблемы можно обсудить с менеджером вне митинга.
Ну, не совсем правы. Если есть фикс. время митинга, то все подстраиваются, если его нет, на митинг забивают. Просто разбейти свой 5ти дневный таск на 5 маленьких подтасков и Вам каждый день будет о чем рассказать. Ну и минус Вашему менеджеру, командный дух не поддерживает.
Ога, а то женщин нам нужен тока секс?
Не лучше IMHO. Даже если работаю над историей на 5 дней, то всё равно часто бывает, что кто-то уже делал что-то похожее, чем занимаюсь я сейчас, и может предложить помощь или совет. Миттинг занимает обычно 5 минут, если у всех всё круто и 10 минут, если есть какие-то проблемы. Команда из 5 системных, 1 sql и 2 embedded разработчиков,
Хотя всё индивидуально. И если работать в большой команде, 20 — 50 разработчиков, то, наверное лучше не мититься каждый день всем.
Хотя всё индивидуально. И если работать в большой команде, 20 — 50 разработчиков, то, наверное лучше не мититься каждый день всем.
Полностью согласен. Кроме того, важно знать чем занимаются другие, чтобы иметь представление, что уже сделано и какие есть проблемы, и в случае чего знать к кому можно обратиться.
Другой вопрос, что грамотно провести стэнд-ап митинг большое искусство, которое требует усилий и практики.
Другой вопрос, что грамотно провести стэнд-ап митинг большое искусство, которое требует усилий и практики.
По Scrum-у, в команде может быть 6, +-3 человека, максимум времени на daily standup — 15 минут. Все стори желательно побить на однодневные таски, обеспечивая таким образом определенный инкремент каждый день. Технические аспекты задач обычно обсуждаются на этапе планирования, и на утренних митингах нужно ответить всего на 3 вопроса: что делал, что будешь делать, и есть ли стопперы.
Мне кажется, проблема именно в пятидневном монолитном таске. Разбив его на небольшие подтаски вы более полно используете возможности Agile. Вы более быстро получите обратную связь по подзаданию, и, возможно, следующие подтаски будете делать совсем по другому, чем планировалось сначала.
А насчет того что впадлу идти на митинг, это связано с тем, что митинги слишком затянуты и/или товарищи рассказывают о таких подробностях, которые вызывают зевоту. ( Именно так все было происходило в моей предыдущей комманде — 1/3 сидела и играла на телефонах, пока главный тестировщик спорил с менеджером о багах которые срочно нужно исправить )
А насчет того что впадлу идти на митинг, это связано с тем, что митинги слишком затянуты и/или товарищи рассказывают о таких подробностях, которые вызывают зевоту. ( Именно так все было происходило в моей предыдущей комманде — 1/3 сидела и играла на телефонах, пока главный тестировщик спорил с менеджером о багах которые срочно нужно исправить )
Плюсую по обоим пунктам:
— у нас, например, максимальная длительность таска — 3 дня. Нужно больше? Разбивай на подзадачи.
— скрам длится 10-15 минут от силы; все затягивающиеся обсуждения нужно выносить.
— у нас, например, максимальная длительность таска — 3 дня. Нужно больше? Разбивай на подзадачи.
— скрам длится 10-15 минут от силы; все затягивающиеся обсуждения нужно выносить.
Вероятно, и вы, и люди выше и ниже правы — многие члены команды начинают на жутко ломаном английском рассказывать о подробностях тасков, а не что они делали. Поэтому и скучно. Сейчас меняю работу, там как раз компания славится весёлыми процессами — возможно, изменю мнение :) А так — пока не покатался на мерседесе, думаешь что все машины похожи на жигули.
1. Таск на 5 дней — исключение. Задача тимлида разбить таски так, чтобы они были достаточно обособленными, при этом занимали 1-2 дня на реализацию (личный опыт), тогда дело движется.
2. Митинг должен длиться не более 15 минут (можете подставить 5, 10 или 20, важно, чтобы рамки были фиксированными), задача модератора митинга, в нашем случае scrum-мастера (работаем по скрам) уложить обсуждение в 15 минут.
3. Профит от митинга состоит в том, чтобы когда один из команды скучным тоном объявил о том, что собирается подправить механизм подгрузки конфигов, так как текущий не походит, другой сказал: «Приятель, а ты учел, что я использую этот механизм в решении задачи отрисовки сообщений и мне не хватает одной фичи/сам уже начал править/пробовал, но наткнулся на грабли.». Возможны варианты, когда один озвучивает намерения, а другой делится опытом реализации сходной задачи, а такой опыт принимается только здесь и сейчас. Куча других бонусов, так как единое информационное пространство крайне важно для эффективной работы.
Не становитесь Петей.
2. Митинг должен длиться не более 15 минут (можете подставить 5, 10 или 20, важно, чтобы рамки были фиксированными), задача модератора митинга, в нашем случае scrum-мастера (работаем по скрам) уложить обсуждение в 15 минут.
3. Профит от митинга состоит в том, чтобы когда один из команды скучным тоном объявил о том, что собирается подправить механизм подгрузки конфигов, так как текущий не походит, другой сказал: «Приятель, а ты учел, что я использую этот механизм в решении задачи отрисовки сообщений и мне не хватает одной фичи/сам уже начал править/пробовал, но наткнулся на грабли.». Возможны варианты, когда один озвучивает намерения, а другой делится опытом реализации сходной задачи, а такой опыт принимается только здесь и сейчас. Куча других бонусов, так как единое информационное пространство крайне важно для эффективной работы.
Не становитесь Петей.
Планирование тасков делается всей командой, а не одним тим лидом. В скраме вообще нет таких фигур, как проект-менеджеры, тим-лиды, и прочие бюрократические личности.
Ничего не говорил про планирование, только про разбитие. Вы рассматриваете варианты разбития по количеству членов команды?
Product Owner выкатывает User Story, задача Development Team-а — реализовать эту стори. Она бьется на таски, таски эстимейтятся, команда определяет definition of done. КАК реализуется стори — задача всей команды. Таски должны быть как можно короче, идеально — однодневными.
Количество членов команды влияет только на количество User Story, которые команда может принять на спринт. К примеру, моя нынешняя — может потянуть один Epic, или 3-4 US, на двухнедельный спринт. Velocity (производительность) команды определяется несколькими спринтами, с планированиями и ретроспективами.
Количество членов команды влияет только на количество User Story, которые команда может принять на спринт. К примеру, моя нынешняя — может потянуть один Epic, или 3-4 US, на двухнедельный спринт. Velocity (производительность) команды определяется несколькими спринтами, с планированиями и ретроспективами.
А раньше на митинги ходили с флагами ((( а слово «совещание» отменили?
Это проблемы перевода, в аджайле митинг от слова — встреча., это просто ежедневная встреча где каждый рассказывает о прогрессе и проблемах. А вот совещание здесь неприемлемо и все они должны быть после митинга между заинтересованными сторонами, чтобы не затягивать митинг и негрузить остальных ненужной информацией.
Слово планёрка — ближе по смыслу, но это как писать код на русском языке.
Слово планёрка — ближе по смыслу, но это как писать код на русском языке.
Я бы тоже говорил «совещание», но все вокруг говорят «митинг» — будут ржать :(
Что теперь «красным флагом» называют… стыдно сказать...;-)
(Я не про китайскую национальную операционную систему)
(Я не про китайскую национальную операционную систему)
Может состояться корректировка задачи, например. Agile позволяет вносить корректировки задачи, для этого тоже нужен стендап.
Квалификация специалистов в комманде разная, вы например можете решить стоппер тремя словами, когда по затупливанию решение может быть найдено через сутки, но вы не решаете стоппер, вы просто легким движением руки направляете разработчика в правильном направлении.
Можно напридумывать из опыта сотни примеров, зачем нужен стендап.
Если хотите — стендап — синхронизация мозгов в комманде. А вы пытаетесь вести себя как Петя из статьи :)
Квалификация специалистов в комманде разная, вы например можете решить стоппер тремя словами, когда по затупливанию решение может быть найдено через сутки, но вы не решаете стоппер, вы просто легким движением руки направляете разработчика в правильном направлении.
Можно напридумывать из опыта сотни примеров, зачем нужен стендап.
Если хотите — стендап — синхронизация мозгов в комманде. А вы пытаетесь вести себя как Петя из статьи :)
Недавно посетил тренинг с Джефом Сюзерлендом, очень умный дядька, дисциплинированный, волевой… говорит умные и полезные вещи… но многое остается за кадром
— мотивация персоонала. Во всех коммандах которые он тренировал был один общий момент — если вы, ребята, не справитесь — этот спринт будет последний. И после этого уже начинается командная игра, люди самоорганизуются, у них вполне конкретный жаренный петух.
— Дисциплина и организация. Если Вы были раздолбаями до гибких методик, то вероятно всего ими же и останетесь после, никакие красивые слова (TDD, FDD, Scrum, и тд) Вам не помогут.
Джеф в прошлом боевой пилот, офицер с дисциплиной и волей… это чувствуется во всем и эту особенность нужно принимать во внимание когда Вы пытаетесь внедрить гибкие аббривиатуры
— мотивация персоонала. Во всех коммандах которые он тренировал был один общий момент — если вы, ребята, не справитесь — этот спринт будет последний. И после этого уже начинается командная игра, люди самоорганизуются, у них вполне конкретный жаренный петух.
— Дисциплина и организация. Если Вы были раздолбаями до гибких методик, то вероятно всего ими же и останетесь после, никакие красивые слова (TDD, FDD, Scrum, и тд) Вам не помогут.
Джеф в прошлом боевой пилот, офицер с дисциплиной и волей… это чувствуется во всем и эту особенность нужно принимать во внимание когда Вы пытаетесь внедрить гибкие аббривиатуры
ну да ну ду последний.
Не забывайте что бывают разработки в которых 2-3 таких «Пети» и 5-6 «мартышек». Петя лабает бекенд зачастую по наитию ибо дорога не протореная не хоженая, о том что нужно сделать знают немногие, о том как сделать незнает никто. Зато если «Пети» справятся — профит будет огромный. А мартышки надо чтобы фронтенд написать и творение Петь в фантик завернуть.
А проблема в чем — том что у Петь — головы квадратные, профит от них такой что им можно еще 3-4 зарплаты платить, и собственно тут они сидели ибо им было интересно и их никто не трогал. Для остальных уровень этих Петь просто недосягаем и многие думают что то, что реализовали Пети просто не возможно по определению ТТХ характеристик оборудования.
Вообщем проще сказать что у Петь надежный такой Job Assurance. И вот приходит такой вот «умный дядька» с военной дисциплиной и начинает гнобить Петь на тему «последний спринт». Петя посылает этого дядьку и идет работать к конкуренту. Epic Fail.
Вообщем мне так эти сектанты- стендаперы уже надоели. Движухи много толку мало. По катку бы им лучше чтоли раздать.
Не забывайте что бывают разработки в которых 2-3 таких «Пети» и 5-6 «мартышек». Петя лабает бекенд зачастую по наитию ибо дорога не протореная не хоженая, о том что нужно сделать знают немногие, о том как сделать незнает никто. Зато если «Пети» справятся — профит будет огромный. А мартышки надо чтобы фронтенд написать и творение Петь в фантик завернуть.
А проблема в чем — том что у Петь — головы квадратные, профит от них такой что им можно еще 3-4 зарплаты платить, и собственно тут они сидели ибо им было интересно и их никто не трогал. Для остальных уровень этих Петь просто недосягаем и многие думают что то, что реализовали Пети просто не возможно по определению ТТХ характеристик оборудования.
Вообщем проще сказать что у Петь надежный такой Job Assurance. И вот приходит такой вот «умный дядька» с военной дисциплиной и начинает гнобить Петь на тему «последний спринт». Петя посылает этого дядьку и идет работать к конкуренту. Epic Fail.
Вообщем мне так эти сектанты- стендаперы уже надоели. Движухи много толку мало. По катку бы им лучше чтоли раздать.
:-) Согласен, Петей быть трудно, но и гордость имеется и ведь есть за что, но Пете стоит осознать, что коллектив сильнее одиночки и сделать может больше если будет работать слаженно, но с Петей сложность в том что он всех считает дебилами, кроме себя любимого и для комманды является сильнейшим демотиватором, поэтому есть следующие варианты
— дать Пете изолированный кусок работы и чтоб не отсвечивал своей гениальностью, а еще лучше целиком проект, чтоб вообще людей не было кроме Пети
— Научить Петю работать в комманде, терпеливо объяснять несовершенным коллегам свои гениальные выкладки и не беситься всякий раз как кто-то усомниться в его исключительности.
— Попрощаться с Петей и пожелать ему всего наилучшего.
— дать Пете изолированный кусок работы и чтоб не отсвечивал своей гениальностью, а еще лучше целиком проект, чтоб вообще людей не было кроме Пети
— Научить Петю работать в комманде, терпеливо объяснять несовершенным коллегам свои гениальные выкладки и не беситься всякий раз как кто-то усомниться в его исключительности.
— Попрощаться с Петей и пожелать ему всего наилучшего.
Проблема в том что только петя понимает как оно работает. И не потому что он злой бармалей и никому не сказал, и не потому что так используются секретные технологии, а потому что нанимали в коллеги пете не шибко квалифицированные кадры. И экономя да и просто не так просто найти десяток петь — они все сидят прикормленные и никуда рыпаться не хотят ибо им тепло сухо мухи не кусают — куда зачем то рыпаться.
Когда я говорил про дисциплину я не имел в виду только инженеров, я имел в виду в первую очередь руководителей, а как следствие уже и всю компанию. Если Ваш начальник раздолбай, то будь вы хоть трижды Петей проект спасти порой будет невозможно.
Такой дядя приходит когда уже предыдущий спринт был последний, деньги почти кончились, а Пете уже не верят и дают последний шанс показать, что прогресс может быть и хотя бы приблизительно посчитать скорость и требующиеся вложения, если работа Пети устраивала стэйкхолдеров никакой дядя не придет.
К стати, такой дядя начинает строить в первую очередь менеджеров устраняя проблемные участки, увеличивая throughput всей системы и к стати Петя у него будет на первом месте в списке уважения и он постарается сделать все чтоб Пете работалось комфортно, без дурацкой дерготни и чтоб петя мог выдать свои 100%
И вот приходит такой вот «умный дядька» с военной дисциплиной и начинает гнобить Петь на тему «последний спринт».
Такой дядя приходит когда уже предыдущий спринт был последний, деньги почти кончились, а Пете уже не верят и дают последний шанс показать, что прогресс может быть и хотя бы приблизительно посчитать скорость и требующиеся вложения, если работа Пети устраивала стэйкхолдеров никакой дядя не придет.
К стати, такой дядя начинает строить в первую очередь менеджеров устраняя проблемные участки, увеличивая throughput всей системы и к стати Петя у него будет на первом месте в списке уважения и он постарается сделать все чтоб Пете работалось комфортно, без дурацкой дерготни и чтоб петя мог выдать свои 100%
В больших фирмах такие дяди часто приходят потому что бюджет есть, а тратить надо.
Есть и такое, но тот пример что привел я несколько из другой области, en.wikipedia.org/wiki/Jeff_Sutherland
Э… Что вы так на Петю? Во-первых он не обязательно самовлюблен до безумия. Но, извините, в абсолютном большинстве коллективы состоят совершенно не из Петь. А из посредственностей. Исследования показывают, что производительность программистов может отличаться в 27 раз.
Программирование — странная область деятельности. Очень отличается от любой другой — здесь не мешки переносить. Здесь всё хуже измеримо. Если человек сидит за компьютером и набирает код, то его производительность может быть как высокой, так и низкой, так и равной нулю, так и отрицательной. И когда собираются люди, у которых огрызок, а не знания и образование. И получается, что команда может быть гораздо менее производительнее, чем один Петя.
Ну например, весь коллектив свято считает, что надо делать вручную всё на своем шарпе, а база нужна для ТОЛЬКО хранения объектов. Т.е. реляционная СУБД по их мнению «создавалась для хранения, а не обработки». Капитан Очевидность заблудился.
Другой человек, допустим, корит за то, что созданный прототип «недостаточно производителен» и не может понять, зачем нужны прототипы.
Гонка за производительностью — это еще тот конек любого неразвитого студента. У неопытных программистов есть такой психологический комплекс — они уверены, что хорошая программа == быстрая программа. И пытаются оптимизировать всё. Потому как видимо боятся упреков от других «джигитов ездящих на красный свет», что если они сделают сразу неоптимальную программу — потеряют уважение. В результате их программы являются очень нехорошими и при этом крайне тормознутыми (непроизводительными), которые отлаживаются по полгода и не становятся производительными никогда.
В общем, прощайтесь с Петей, Пете наверное будет так лучше, чем работать бог весть с кем. В программирование сумма людей не очень коррелирует с производительностью и качеством. Аджайл — отличное средство. Но отнюдь не обязательно всех впрягать на равных и слушать всех, что как надо делать. Петя в этом же скраме может брать куски поответственнее и побольше.
И… Нет в программировании ничего гениального. Большинство задач — слабоинтеллектуальные. И образование программиста (высшее), довольно слабое по программе. Не верите? Попробуйте теоретическую физику.
В понимании Петь, они не делают ничего гениального. Но бывает, что реально сил и желания не хватает объяснять очевидные вещи. А те, кто думают, что Петя в чем-то гений… Вот им и тяжело объяснять. Причем объяснять, видимо, надо не один раз. Но при этом и не получается — Петя пишет суровый код, а не модный. Моду диктует большинство. А большинство из-за низкого порога вхождения, чаще всего склоняется к какой-то чуши.
Программирование — странная область деятельности. Очень отличается от любой другой — здесь не мешки переносить. Здесь всё хуже измеримо. Если человек сидит за компьютером и набирает код, то его производительность может быть как высокой, так и низкой, так и равной нулю, так и отрицательной. И когда собираются люди, у которых огрызок, а не знания и образование. И получается, что команда может быть гораздо менее производительнее, чем один Петя.
Ну например, весь коллектив свято считает, что надо делать вручную всё на своем шарпе, а база нужна для ТОЛЬКО хранения объектов. Т.е. реляционная СУБД по их мнению «создавалась для хранения, а не обработки». Капитан Очевидность заблудился.
Другой человек, допустим, корит за то, что созданный прототип «недостаточно производителен» и не может понять, зачем нужны прототипы.
Гонка за производительностью — это еще тот конек любого неразвитого студента. У неопытных программистов есть такой психологический комплекс — они уверены, что хорошая программа == быстрая программа. И пытаются оптимизировать всё. Потому как видимо боятся упреков от других «джигитов ездящих на красный свет», что если они сделают сразу неоптимальную программу — потеряют уважение. В результате их программы являются очень нехорошими и при этом крайне тормознутыми (непроизводительными), которые отлаживаются по полгода и не становятся производительными никогда.
В общем, прощайтесь с Петей, Пете наверное будет так лучше, чем работать бог весть с кем. В программирование сумма людей не очень коррелирует с производительностью и качеством. Аджайл — отличное средство. Но отнюдь не обязательно всех впрягать на равных и слушать всех, что как надо делать. Петя в этом же скраме может брать куски поответственнее и побольше.
И… Нет в программировании ничего гениального. Большинство задач — слабоинтеллектуальные. И образование программиста (высшее), довольно слабое по программе. Не верите? Попробуйте теоретическую физику.
В понимании Петь, они не делают ничего гениального. Но бывает, что реально сил и желания не хватает объяснять очевидные вещи. А те, кто думают, что Петя в чем-то гений… Вот им и тяжело объяснять. Причем объяснять, видимо, надо не один раз. Но при этом и не получается — Петя пишет суровый код, а не модный. Моду диктует большинство. А большинство из-за низкого порога вхождения, чаще всего склоняется к какой-то чуши.
Попробуйте отвлечься от образа мышления Пети и представить себя в роли его руководителя. У Вас все хорошо пока Петя справляется, даже если на него жалуются другие члены комманды, но проект успешен — вас это не особо напрягает, вы выслушаете недовольных, попеняете на характеры, что-то сделаете в плане разрядки ситуации, но кардинально менять ничего не будете, денежка капает, клиенты довольны.
А вот другая ситуация, проекты стали амбициозней — один Петя уже не справляется, даете ему людей в помощь или в подчинение — начинаются конфликты, он конечно звезда, но нужно работу делать, а не восхвалять его глубокие знания которые Вам сейчас не помогают, т.е. он все сделать сам не может и морально угнетает коллектив в результатет производительность еще хуже.
А такая ситуация рано или поздно случиться ибо Петя не семи-жильный, но привык что он звезда. Потребуется работа в коллективе, пусть не таком одаренном как он, но тем не менее тоже работоспособном. И чем шире будет Ваш бизнес тем больше задач, а Петя даже 1 задачу уже самостоятельно потянуть не может, нужны дополнительные люди. Ничего личного, но либо Петя учится работать с «не звездами» либо нужно отводить его в отельный загончик и при иссякании задач «его масштаба» вежливо и дружелюбно прощаться.
Я не предлагаю всех впрягать одинаково, но если задач для Пети как самостоятельной единицы нет, а работать с людьми не его конек — то кормить Петю придется кому-то другому.
Если же Петя нормально уживается с другими людьми, может работать в комманде или справляется сам с поставленными задачами, проект успешен, то не важно как это обозвать — Scrumm, XP и тд… важен результат, а не процесс.
А вот другая ситуация, проекты стали амбициозней — один Петя уже не справляется, даете ему людей в помощь или в подчинение — начинаются конфликты, он конечно звезда, но нужно работу делать, а не восхвалять его глубокие знания которые Вам сейчас не помогают, т.е. он все сделать сам не может и морально угнетает коллектив в результатет производительность еще хуже.
А такая ситуация рано или поздно случиться ибо Петя не семи-жильный, но привык что он звезда. Потребуется работа в коллективе, пусть не таком одаренном как он, но тем не менее тоже работоспособном. И чем шире будет Ваш бизнес тем больше задач, а Петя даже 1 задачу уже самостоятельно потянуть не может, нужны дополнительные люди. Ничего личного, но либо Петя учится работать с «не звездами» либо нужно отводить его в отельный загончик и при иссякании задач «его масштаба» вежливо и дружелюбно прощаться.
Аджайл — отличное средство. Но отнюдь не обязательно всех впрягать на равных и слушать всех, что как надо делать. Петя в этом же скраме может брать куски поответственнее и побольше.
Я не предлагаю всех впрягать одинаково, но если задач для Пети как самостоятельной единицы нет, а работать с людьми не его конек — то кормить Петю придется кому-то другому.
Если же Петя нормально уживается с другими людьми, может работать в комманде или справляется сам с поставленными задачами, проект успешен, то не важно как это обозвать — Scrumm, XP и тд… важен результат, а не процесс.
Да я ж и говорю — кормите не Петю, а толпу, которая не доведет сама ни одного проекта до ума.
Если Петя угнетает коллектив — то тут взвесить надо и возможно прощаться. Атмосфера в коллективе — наше всё. Но надо вообще аккуратно смотреть за ситуацией. Может вам кажется, что с уходом Пети атмосфера повлияет положительно на общую производительность? Сумма людей не гарантирует скорость и качество. Наймите еще сто, это не скажется положительно на проекте.
Идеальный, но тяжело достижимый вариант, нанять несколько Петь, которые бы ладили между собой и все были хорошими специалистами. Кормить же больше людей с меньшей зарплатой невыгодно, потому что они проедают больше, если оценивать производительность работы и качество. Потеря Пети может фатально сказаться на проекте. Потому что даже если Петя и портит где-то атмосферу, он является якорем, который может остановить ненужные фантазии и посоветовать, как надо развивать проект дальше.
Поверьте, 20 обезьян не заменят Толстого.
Если Петя угнетает коллектив — то тут взвесить надо и возможно прощаться. Атмосфера в коллективе — наше всё. Но надо вообще аккуратно смотреть за ситуацией. Может вам кажется, что с уходом Пети атмосфера повлияет положительно на общую производительность? Сумма людей не гарантирует скорость и качество. Наймите еще сто, это не скажется положительно на проекте.
Идеальный, но тяжело достижимый вариант, нанять несколько Петь, которые бы ладили между собой и все были хорошими специалистами. Кормить же больше людей с меньшей зарплатой невыгодно, потому что они проедают больше, если оценивать производительность работы и качество. Потеря Пети может фатально сказаться на проекте. Потому что даже если Петя и портит где-то атмосферу, он является якорем, который может остановить ненужные фантазии и посоветовать, как надо развивать проект дальше.
Поверьте, 20 обезьян не заменят Толстого.
Вариантов много, рецепта однозначного нет. По мне лучше 2-3 крепких середнячка ладящих друг с другом, чем одна звезда с самомнением, кто-то считает что наймет звезду и он в 27 раз быстрее все сделает, кто-то в этом сомневается, рационально полагая что выполнив 90% проекта в разы быстрее человек не сможет покрыть оставшиеся 10 и не сможет скооперироваться с другими людьми чтоб исправить положение. Тут как фишка ляжет и на сколько хорошим психологом и переговорщиком будет руководитель звезды и на сколько терпеливы и мудры будут остальные члены команды.
По ситуации.
Он по факту «звезда» или самомнение такое? Судя по статье — по факту. Если большое самомнение, то чаще бывает как раз наоборот. Как-то между высоким ЧСВ и низкими интеллектуальными способностями замечена серьезная корреляция.
Звезд как и гениальности не бывает. В нашем простом деле. Но если он реально намного опытнее, то потеря может сильно ударить, если не убить производительность. Иногда приходится идти на конфликт, когда городят полную ерунду. Еще раз повторю: и три середнячка обычно не смогут заменить более опытного.
Дело в том, что часто конфликты бывают по теме. Если люди неопытные, то они неуютно ощущают себя, если их без конца кто-то останавливает. Но один такой конфликт, который подпортил на день настроение кому-то может стоять много месяцев работы. Неопытные программисты не знают, что в какой последовательности делать и что лучше. И часто просто ищут фан в работе — прикрутить модный фреймфорк, соорудить какую-то ахинею, денормализовать базу (потому что так прикольнее) и т.д. Иногда, бывали конфликты, когда проект вообще на грани возможного — т.е. либо получится, либо нет — а вот, люди хотят делать то, что явно его убьет. И когда они не хотят понимать или прислушаться, приходится конфликтовать. Лучше вывести кого-то из зоны комфорта, чем потерять полгода. Правда?
А если такой человек пропадает и остаются в конторе середнячки? Хорошо, если они делают то, что делали всегда. Такой человек, как Петя, может просто определить оптимальный беспроигрышный путь. А толпа из 10 человек может написать много кода (больше Пети) и заблудиться.
Он по факту «звезда» или самомнение такое? Судя по статье — по факту. Если большое самомнение, то чаще бывает как раз наоборот. Как-то между высоким ЧСВ и низкими интеллектуальными способностями замечена серьезная корреляция.
Звезд как и гениальности не бывает. В нашем простом деле. Но если он реально намного опытнее, то потеря может сильно ударить, если не убить производительность. Иногда приходится идти на конфликт, когда городят полную ерунду. Еще раз повторю: и три середнячка обычно не смогут заменить более опытного.
Дело в том, что часто конфликты бывают по теме. Если люди неопытные, то они неуютно ощущают себя, если их без конца кто-то останавливает. Но один такой конфликт, который подпортил на день настроение кому-то может стоять много месяцев работы. Неопытные программисты не знают, что в какой последовательности делать и что лучше. И часто просто ищут фан в работе — прикрутить модный фреймфорк, соорудить какую-то ахинею, денормализовать базу (потому что так прикольнее) и т.д. Иногда, бывали конфликты, когда проект вообще на грани возможного — т.е. либо получится, либо нет — а вот, люди хотят делать то, что явно его убьет. И когда они не хотят понимать или прислушаться, приходится конфликтовать. Лучше вывести кого-то из зоны комфорта, чем потерять полгода. Правда?
А если такой человек пропадает и остаются в конторе середнячки? Хорошо, если они делают то, что делали всегда. Такой человек, как Петя, может просто определить оптимальный беспроигрышный путь. А толпа из 10 человек может написать много кода (больше Пети) и заблудиться.
Весьма категоричные суждения:
Это красивые лозунги, но они идут в разрез с опытом который имею я.
PS: середняки это не дебилы — это крепкие профессионалы которые не выдадут 120%, но 90% вы от них можете ожидать почти в любом раскладе, они умны, не сидят на пьедистале и выдают предсказуемо хороший результат. А вот от звезды вы можете получить как 2700% так и — 2700% в зависимости от его настроения и фазы луны :-) Опять же, это мой опыт, если у Вас другой, я искренне за Вас рад.
Как-то между высоким ЧСВ и низкими интеллектуальными способностями замечена серьезная корреляция
Звезд как и гениальности не бывает.
В нашем простом деле.
Еще раз повторю: и три середнячка обычно не смогут заменить более опытного.
Такой человек, как Петя, может просто определить оптимальный беспроигрышный путь.
Это красивые лозунги, но они идут в разрез с опытом который имею я.
PS: середняки это не дебилы — это крепкие профессионалы которые не выдадут 120%, но 90% вы от них можете ожидать почти в любом раскладе, они умны, не сидят на пьедистале и выдают предсказуемо хороший результат. А вот от звезды вы можете получить как 2700% так и — 2700% в зависимости от его настроения и фазы луны :-) Опять же, это мой опыт, если у Вас другой, я искренне за Вас рад.
Я беру среднее по рынку, с чем сталкивался.
Если ваши середняки от самых опытных отличаются всего лишь более медленной, но уверенной работой, то это по-моему не середняки. Если вопрос только в том, сколько кода может родить и за какое время, но при этом такой середняк правильно определяет, что делать дальше — то тут можно согласиться.
Как раз проблема не в том, что кто-то за час чуть меньше кода дает, а в том, что код не в ту степь. Иногда ненужный, а иногда просто таки вредный. Преимущество Пети далеко не в скорости набора, хотя и это тоже, а в том, что выбирает наиболее правильную последовательность действий. И вообще, бывает так, что сделает за неделю то, что будут несколько человек пару месяцев делать. Потому, что кода у него будет меньше. А у тех, кто делает несколько месяцев — бешенные трудозатраты, потому что код решает даже не поставленную задачу, а черт знает что.
Вот пример смешноватой ситуации. Человек создает «конечный автомат». Но не знает, что это такое. При этом задача поставлена, и как себе представляет, так и создает. Суть задачи, чтобы система переходила в нужное состояние после некоторого события.
При этом такой автомат должен быть инстансом для каждого отдельного пользователя.
Этот программист, который считает себя опытным и быстро делающим задачи, вдруг выдумывает, что в этом месте будет тормозить. Поэтому он делает автомат ассинхронным. Т.е. еще до того, как перейти в новое состояние, рапортует, что он в него перешел.
Преждевременная оптимизация противоречит даже функциональной цели задачи. В итоге, полгода это ставилось на ноги. А сделать такой автомат без предварительной оптимизации — не более нескольких страниц. (И готов поклясться, что оптимизировать не надо будет, т.к. он обрабатывает 1 (!!!) пользователя и нет никаких циклов)
И так постоянно. Если бы были середнячки, которые просто медленнее работают, но хорошо понимают эволюционное проектирование, ТДД, как проектировать БД, как рефакторить и то и другое — да это просто супер-коллектив. Но как показывает практика, такого нет нигде. Это надо вводить. Этому надо учить. За счет конторы.
Если ваши середняки от самых опытных отличаются всего лишь более медленной, но уверенной работой, то это по-моему не середняки. Если вопрос только в том, сколько кода может родить и за какое время, но при этом такой середняк правильно определяет, что делать дальше — то тут можно согласиться.
Как раз проблема не в том, что кто-то за час чуть меньше кода дает, а в том, что код не в ту степь. Иногда ненужный, а иногда просто таки вредный. Преимущество Пети далеко не в скорости набора, хотя и это тоже, а в том, что выбирает наиболее правильную последовательность действий. И вообще, бывает так, что сделает за неделю то, что будут несколько человек пару месяцев делать. Потому, что кода у него будет меньше. А у тех, кто делает несколько месяцев — бешенные трудозатраты, потому что код решает даже не поставленную задачу, а черт знает что.
Вот пример смешноватой ситуации. Человек создает «конечный автомат». Но не знает, что это такое. При этом задача поставлена, и как себе представляет, так и создает. Суть задачи, чтобы система переходила в нужное состояние после некоторого события.
При этом такой автомат должен быть инстансом для каждого отдельного пользователя.
Этот программист, который считает себя опытным и быстро делающим задачи, вдруг выдумывает, что в этом месте будет тормозить. Поэтому он делает автомат ассинхронным. Т.е. еще до того, как перейти в новое состояние, рапортует, что он в него перешел.
Преждевременная оптимизация противоречит даже функциональной цели задачи. В итоге, полгода это ставилось на ноги. А сделать такой автомат без предварительной оптимизации — не более нескольких страниц. (И готов поклясться, что оптимизировать не надо будет, т.к. он обрабатывает 1 (!!!) пользователя и нет никаких циклов)
И так постоянно. Если бы были середнячки, которые просто медленнее работают, но хорошо понимают эволюционное проектирование, ТДД, как проектировать БД, как рефакторить и то и другое — да это просто супер-коллектив. Но как показывает практика, такого нет нигде. Это надо вводить. Этому надо учить. За счет конторы.
У нас нет текучки кадров, средная продолжительность работы 7 лет, опытные инженеры с 10-15-20 летним стажем, это наши «середняки» и «рабочие лошадки». Есть несколько звезд, у них нет личной жизни, ничего кроме работы, они фанатики, но с очень специфичной психикой, плохой управляемостью и предсказуемостью. Их можно бросить заткнуть какую-то дыру и они фанатично кинутся веря в себя что справятся за месяц (и реально могут справиться, как подфартит), когда середняк скажет «на это нужно 3-4 месяца» и не обманет, но за это время получишь удовлетворяющее решение.
Основное направление работы R&D, т.е. вопрос в скорости набора кода не стоит, стоит вопрос как быстро человек находит и воплощает решение для новой/нестандартной проблемы и может ли свое решение довести до ума и что еще важно поддерживать его если будет на него спрос.
Основное направление работы R&D, т.е. вопрос в скорости набора кода не стоит, стоит вопрос как быстро человек находит и воплощает решение для новой/нестандартной проблемы и может ли свое решение довести до ума и что еще важно поддерживать его если будет на него спрос.
Может быть у вас хорошо, но описание сильно настораживает.
Личный опыт говорит:
1. Если программист бегает с конторы в контору чаще, чем раз в году — плохой программист.
2. Если программист не меняет контору реже, чем три года (приблизительно) — плохой программист.
Менять работу нужно, чтобы обмениваться опытом. Программист развивается в коллективе. Например, в провинциях люди в принципе не тупее. Но там нет достаточной конкуренции между работодателями и люди варятся в собственном соку. Знания плачевные. Еще хуже бывает только на фрилансе, когда программист вообще не работал в живом коллективе. Программирование хоть и не слишком интеллектуальное занятие, но требует много учить, много помнить и всё время развиваться. Когда человек не имеет даже критериев, что такое хороший программист, когда не с кем себя сравнить, то не будет и развития.
Я, было дело, работал недолго в одной конторе и мне хвастались при приеме на работу, что минимум по 7 лет работали все люди. Они со временем ушли и мне пришлось одному развивать и поддерживать продукт. Руководство хвалило бывших сотрудников, как очень умных, которые после ВУЗа сразу пошли к ним работать и делали продукт много лет. Многие «победители олимпиад».
В коде такой страх!!! Просто был шокирован, как руководство до сих пор питает иллюзии на счет «хороших работников». Причем постоянно теряет большие деньги, когда что-то ломается. Ну и ломалось оно далеко не зря. 10 лет продукт делают (для себя), а жесть такая — никак не отладится.
Второй нюанс в ваших сообщениях, который мне напомнил ту контору. Вы пишете «как руководитель» по поводу того, что мол, у людей психика неуравновешенная и т.д. Я уволился, правда не сразу с той конторы.
Так вот: у моего прямого начальника, не программиста, был РПЦ головного мозга. Странно, но это может мешать работать. Например, он (ну кроме деления, что либо от бога, либо от сатаны), считал, что если я хоть что-то утверждаю, что надо и как делать — то это «гордыня», а отнюдь не рациональное предложение. Ну да ладно, это не сильно мешало, т.к. программист то был я один и многое делал сам без согласований.
Кроме РПЦ ГМ у начальника было убеждение, что нельзя вообще никаких споров, что кругом должна быть гармония и что нигде нельзя никому переходить дорогу.
Извините за длинное вступление, тяжело объяснить без этого простую идею. Есть точные науки, а есть гуманитарные. Люди с гуманитарным мышлением думают именно о гармонии взаимоотношений и ни о чем более. У них есть такая формула: «Каждый имеет право на свое мнение и каждый прав по своему». У людей с точным складом ума такой формулы нет. Человек либо прав либо не прав — и это объективная вещь. И прекрасно, если люди умеют прямо об этом говорить и они открыты для обсуждения, не боясь обидеть чье-то ЧСВ. Не переходят на личности. И не воспринимают критику, как собственную обиду.
Я считаю, что программисты должны быть именно такими. Не раз сталкивался с огромными потерями для компании, когда начинались взаимоотношения на уровне «человеческих отношений».
Еще что настораживает в вашем сообщении. Программирование — это работа с информацией. Всё время что-то меняется. Это значит, что программист работает не в детерминированном окружении. Меняются требования, появляются баги (обязательно), появляются новые знания о том, с чем работаешь (например, о библиотеках от третьих лиц). Это факт. Объективный и научно обоснованный. Но к сожалению, бизнес еще не вырос и всё еще руководствуется идеалистическими субъективными представлениями. Вроде «обещания», «пацан сказал, пацан сделал». И как-то бизнес даже не всегда понимая зачем, руководствуется планами. Людям так теплее себя ощущать.
Я это к тому, что профи в программировании вряд ли точный в оценках сроков. Но он зато знает в любой момент времени как поступить наилучшим образом. Он не считает себя богом, который гарантирует, что завтра не пойдет снег. Но он гарантирует, что в любой ситуации поступит наиболее оптимальным способом. В результате у такого специалиста всегда время выполнения задачи меньше и всегда качество выполнения лучше. И я никак не могу врубиться, когда мне утверждают: выполни задачу лучше за год, а не за месяц, но так, чтобы это было гарантированно. Извините, вам не в лом платить 11 лишних месяцев?
Вот приблизительно так со стороны руководства, не понимающего в программировании и думают: «этот человек пусть медленно, но делает что-то и мы можем надеяться что он сделает ровно за то время, что сказал „приемлемое решение“. А этот Петя делает гарантированно всегда быстрее и даже лучше, но мы не можем от него добиться, чтобы он сказал, когда это будет».
В общем, если думать о целевой функции «получение бОльших денег за меньшее время», то надо выбирать Петь. Но бизнес видимо не деньги хочет, а послушание.
При этом «приемлемое решение» от середнячков, как правило, теми, кто не понимает в программировании, не может и проверяться на приемлемость. Плюс, раз у них всегда что-то получается в срок — то лучше проследите за ними, значит у них огромная временная подушка и они за ваши деньги страдают ерундой.
Личный опыт говорит:
1. Если программист бегает с конторы в контору чаще, чем раз в году — плохой программист.
2. Если программист не меняет контору реже, чем три года (приблизительно) — плохой программист.
Менять работу нужно, чтобы обмениваться опытом. Программист развивается в коллективе. Например, в провинциях люди в принципе не тупее. Но там нет достаточной конкуренции между работодателями и люди варятся в собственном соку. Знания плачевные. Еще хуже бывает только на фрилансе, когда программист вообще не работал в живом коллективе. Программирование хоть и не слишком интеллектуальное занятие, но требует много учить, много помнить и всё время развиваться. Когда человек не имеет даже критериев, что такое хороший программист, когда не с кем себя сравнить, то не будет и развития.
Я, было дело, работал недолго в одной конторе и мне хвастались при приеме на работу, что минимум по 7 лет работали все люди. Они со временем ушли и мне пришлось одному развивать и поддерживать продукт. Руководство хвалило бывших сотрудников, как очень умных, которые после ВУЗа сразу пошли к ним работать и делали продукт много лет. Многие «победители олимпиад».
В коде такой страх!!! Просто был шокирован, как руководство до сих пор питает иллюзии на счет «хороших работников». Причем постоянно теряет большие деньги, когда что-то ломается. Ну и ломалось оно далеко не зря. 10 лет продукт делают (для себя), а жесть такая — никак не отладится.
Второй нюанс в ваших сообщениях, который мне напомнил ту контору. Вы пишете «как руководитель» по поводу того, что мол, у людей психика неуравновешенная и т.д. Я уволился, правда не сразу с той конторы.
Так вот: у моего прямого начальника, не программиста, был РПЦ головного мозга. Странно, но это может мешать работать. Например, он (ну кроме деления, что либо от бога, либо от сатаны), считал, что если я хоть что-то утверждаю, что надо и как делать — то это «гордыня», а отнюдь не рациональное предложение. Ну да ладно, это не сильно мешало, т.к. программист то был я один и многое делал сам без согласований.
Кроме РПЦ ГМ у начальника было убеждение, что нельзя вообще никаких споров, что кругом должна быть гармония и что нигде нельзя никому переходить дорогу.
Извините за длинное вступление, тяжело объяснить без этого простую идею. Есть точные науки, а есть гуманитарные. Люди с гуманитарным мышлением думают именно о гармонии взаимоотношений и ни о чем более. У них есть такая формула: «Каждый имеет право на свое мнение и каждый прав по своему». У людей с точным складом ума такой формулы нет. Человек либо прав либо не прав — и это объективная вещь. И прекрасно, если люди умеют прямо об этом говорить и они открыты для обсуждения, не боясь обидеть чье-то ЧСВ. Не переходят на личности. И не воспринимают критику, как собственную обиду.
Я считаю, что программисты должны быть именно такими. Не раз сталкивался с огромными потерями для компании, когда начинались взаимоотношения на уровне «человеческих отношений».
Еще что настораживает в вашем сообщении. Программирование — это работа с информацией. Всё время что-то меняется. Это значит, что программист работает не в детерминированном окружении. Меняются требования, появляются баги (обязательно), появляются новые знания о том, с чем работаешь (например, о библиотеках от третьих лиц). Это факт. Объективный и научно обоснованный. Но к сожалению, бизнес еще не вырос и всё еще руководствуется идеалистическими субъективными представлениями. Вроде «обещания», «пацан сказал, пацан сделал». И как-то бизнес даже не всегда понимая зачем, руководствуется планами. Людям так теплее себя ощущать.
Я это к тому, что профи в программировании вряд ли точный в оценках сроков. Но он зато знает в любой момент времени как поступить наилучшим образом. Он не считает себя богом, который гарантирует, что завтра не пойдет снег. Но он гарантирует, что в любой ситуации поступит наиболее оптимальным способом. В результате у такого специалиста всегда время выполнения задачи меньше и всегда качество выполнения лучше. И я никак не могу врубиться, когда мне утверждают: выполни задачу лучше за год, а не за месяц, но так, чтобы это было гарантированно. Извините, вам не в лом платить 11 лишних месяцев?
Вот приблизительно так со стороны руководства, не понимающего в программировании и думают: «этот человек пусть медленно, но делает что-то и мы можем надеяться что он сделает ровно за то время, что сказал „приемлемое решение“. А этот Петя делает гарантированно всегда быстрее и даже лучше, но мы не можем от него добиться, чтобы он сказал, когда это будет».
В общем, если думать о целевой функции «получение бОльших денег за меньшее время», то надо выбирать Петь. Но бизнес видимо не деньги хочет, а послушание.
При этом «приемлемое решение» от середнячков, как правило, теми, кто не понимает в программировании, не может и проверяться на приемлемость. Плюс, раз у них всегда что-то получается в срок — то лучше проследите за ними, значит у них огромная временная подушка и они за ваши деньги страдают ерундой.
Извиняюсь, но я критически ограничено во времени и обсудить все Ваши мысли к сожалению не смогу, скажу лишь что со многим согласен, с чем то бы поспорил.
Постараюсь еще раз пояснить свою точку зрения касательно Пети — конфликтность для меня заключается в следующем — он спорит с людьми так что они потом не хотят с ним работать, либо он не хочет с ними работать так как они с ним не соглашаются сразу ведь он авторитет, Петя — человек асоциальный и это перечеркивает много его заслуг и плюсов когда речь заходит о коммандной работе. Если Петя может спорить и сотрудничать без плачевных последствий для коммандной работы то такой Петя хороший Петя, если не может то либо есть под него задачи и мы работаем либо прощаемся. Прошу прощения если задел Вас за какие то личные струнки, совсем не имел это целью. Удачных выходных и с наступающим.
Постараюсь еще раз пояснить свою точку зрения касательно Пети — конфликтность для меня заключается в следующем — он спорит с людьми так что они потом не хотят с ним работать, либо он не хочет с ними работать так как они с ним не соглашаются сразу ведь он авторитет, Петя — человек асоциальный и это перечеркивает много его заслуг и плюсов когда речь заходит о коммандной работе. Если Петя может спорить и сотрудничать без плачевных последствий для коммандной работы то такой Петя хороший Петя, если не может то либо есть под него задачи и мы работаем либо прощаемся. Прошу прощения если задел Вас за какие то личные струнки, совсем не имел это целью. Удачных выходных и с наступающим.
Гы ))
Точно такая была недавно ситуация, я в роли Пети. Пришел человек и начал агрессивно со мной говорить в том плане, что мой прототип (задача искусственного интеллекта) по его мнению плохой, потому что не очень быстро работает. Полюбовно поматерились друг на друга и сошлись на том, что не хотим работать друг с другом.
Ситуации могут быть разные. Если слишком большая разница в опыте и знаниях, то такие ссоры неизбежны. Ну, представляете, когда человек не врубается даже, что такое прототип и какие у него задачи? Но при этом не хочет воспринимать меня как авторитет. Как можно с таким работать? Просто не сложатся никакие рабочие отношения. Ситуация, вроде пришел профессор квантовой физики в детский сад и рассказывает популярно про электроны, а дети: «Враки всё это. Наш дворник дядя Вася говорит, что нет никаких электронов. А кто ты такой?».
Надо сказать, что я сейчас в несофтверной компании работаю. Не хотел в такую компанию идти, но посоветовали общие знакомые. И не жалею, потому что в таких компаниях можно встретить гораздо интереснее задачи. Но бывают казусы, вроде «архитектор с 2-мя годами опыта после института».
Конфликтовать плохо, согласен. Очень важно, чтобы отношения в коллективе были хорошими. Потому как жизнь состоит из работы и хочется, чтобы и дальше хотелось туда ходить. И Вам решать, что делать с Петей. Если он необоснованно ругается и вообще портит атмосферу и является заменимым, то вполне возможно лишний.
Но это не сходится. Если Петя реально опережает по качеству и срокам, то значит есть же у него какой-то секрет. Надо у него чему-то поучиться.
Точно такая была недавно ситуация, я в роли Пети. Пришел человек и начал агрессивно со мной говорить в том плане, что мой прототип (задача искусственного интеллекта) по его мнению плохой, потому что не очень быстро работает. Полюбовно поматерились друг на друга и сошлись на том, что не хотим работать друг с другом.
Ситуации могут быть разные. Если слишком большая разница в опыте и знаниях, то такие ссоры неизбежны. Ну, представляете, когда человек не врубается даже, что такое прототип и какие у него задачи? Но при этом не хочет воспринимать меня как авторитет. Как можно с таким работать? Просто не сложатся никакие рабочие отношения. Ситуация, вроде пришел профессор квантовой физики в детский сад и рассказывает популярно про электроны, а дети: «Враки всё это. Наш дворник дядя Вася говорит, что нет никаких электронов. А кто ты такой?».
Надо сказать, что я сейчас в несофтверной компании работаю. Не хотел в такую компанию идти, но посоветовали общие знакомые. И не жалею, потому что в таких компаниях можно встретить гораздо интереснее задачи. Но бывают казусы, вроде «архитектор с 2-мя годами опыта после института».
Конфликтовать плохо, согласен. Очень важно, чтобы отношения в коллективе были хорошими. Потому как жизнь состоит из работы и хочется, чтобы и дальше хотелось туда ходить. И Вам решать, что делать с Петей. Если он необоснованно ругается и вообще портит атмосферу и является заменимым, то вполне возможно лишний.
Но это не сходится. Если Петя реально опережает по качеству и срокам, то значит есть же у него какой-то секрет. Надо у него чему-то поучиться.
Ну, не спешите с минусами. Реально люди бывают очень разными и опыты разными. Я Вам, как руководителю, если вы не разбираетесь в самом программировании, советую присмотреться к Петям и их конфликтам. Нельзя делать вывод просто на том, что вокруг Пети одни конфликты, и он виноват.
У меня конфликт был, вот выше, даже не с начальником, просто коллегой, который решил меня поучить вдруг, как надо писать прототипы. Оказывается, по его мнению, я должен был распланировать его, построить диаграммы, утвердить у начальства и продумать изначально, чтобы он быстро работал. Надо сказать, что прототип в данной задаче как раз выполнял роль — проверить вообще, будет ли модель, мною придуманная работать. Было не известно, получится ли вообще такая штука. Т.к. ее никто не сделал.
И вот человек решил меня поучить «водопаду». Естественно, такие задачи ему в принципе не по зубам, но при этом он знает, как я должен был поступать.
Я не жалуюсь на него и это не для жалоб место. Просто как раз точно он напоминает середняка вашего. Он пишет код, но долго. Долго планирует, рисует схемы. Простая задача может у него занять пару месяцев. Прямо по вашему — прогнозируемый середняк.
Но. Если Вы не просто начальник, а платите деньги из своего кармана (владелец), то здесь уже совсем что-то не то. Почему Петям не платят в 3 раза больше денег, если они делают за месяц задачу, которую середняк делает за 3? С чего вдруг долгая медленная работа с «приемлемым» результатом оказывается более подходящей, чем работа Пети? Где же логика.
У меня конфликт был, вот выше, даже не с начальником, просто коллегой, который решил меня поучить вдруг, как надо писать прототипы. Оказывается, по его мнению, я должен был распланировать его, построить диаграммы, утвердить у начальства и продумать изначально, чтобы он быстро работал. Надо сказать, что прототип в данной задаче как раз выполнял роль — проверить вообще, будет ли модель, мною придуманная работать. Было не известно, получится ли вообще такая штука. Т.к. ее никто не сделал.
И вот человек решил меня поучить «водопаду». Естественно, такие задачи ему в принципе не по зубам, но при этом он знает, как я должен был поступать.
Я не жалуюсь на него и это не для жалоб место. Просто как раз точно он напоминает середняка вашего. Он пишет код, но долго. Долго планирует, рисует схемы. Простая задача может у него занять пару месяцев. Прямо по вашему — прогнозируемый середняк.
Но. Если Вы не просто начальник, а платите деньги из своего кармана (владелец), то здесь уже совсем что-то не то. Почему Петям не платят в 3 раза больше денег, если они делают за месяц задачу, которую середняк делает за 3? С чего вдруг долгая медленная работа с «приемлемым» результатом оказывается более подходящей, чем работа Пети? Где же логика.
Хорошо, с точки зрения Пети все выглядит логично, но представте себе его руководителя, он ценит Петю, знает что тот весьма эффективен в определенных задачах, но вот случился конфликт Пети и еще кого-то, трудно понять кто виноват, замяли, но осадок остался, потом еще один, еще и еще, с разными людьми но зачастую вторая сторона это Петя. Уволить всех остальных и оставить только Петю — не вариант, он не потянет всё, в сутках только 24 часа. Если ваш руководитель ведет банальную статистику конфликтов то личности их геренирующие видны как на ладони, есть конечно маленький шанс что Петя стал жертвой заговора бездарностей и серости, но чем больше накопленная статистика тем меньше этот шанс.
Почему Пете не платят в 3 раза выше если он эффективнее в 3 раза? Допустим Вы правы и Петя не переоценивает себя и стоит 3х человек. Причин не платить ему в 3 раза больше очень много — ему не куда идти, ни кто не поверит в его сверх эффективность, Петя не требует повышения ЗП и еще тележка других причин, общее у них одно — если есть хоть один шанс не платить больше — им нужно воспользоваться, это не всегда самая лучшая политика, но бол-во мыслят именно так. Чтоб платить в 3 раза больше нужно почти безвыходное положение, т.е. если не заплатишь будет еще хуже. Плюс мотивирование деньгами не самое эффективное, а после определенного рубежа работает в обратном направлении развращая человека.
Почему Пете не платят в 3 раза выше если он эффективнее в 3 раза? Допустим Вы правы и Петя не переоценивает себя и стоит 3х человек. Причин не платить ему в 3 раза больше очень много — ему не куда идти, ни кто не поверит в его сверх эффективность, Петя не требует повышения ЗП и еще тележка других причин, общее у них одно — если есть хоть один шанс не платить больше — им нужно воспользоваться, это не всегда самая лучшая политика, но бол-во мыслят именно так. Чтоб платить в 3 раза больше нужно почти безвыходное положение, т.е. если не заплатишь будет еще хуже. Плюс мотивирование деньгами не самое эффективное, а после определенного рубежа работает в обратном направлении развращая человека.
Статистика, это такая штука, которая далеко не всегда говорит о причинах. По статистике я каждое утро иду на работу и солнце на небе появляется. Но честно, не я причина.
Банально, если разница в знаниях очень большая, то конфликты неизбежны, если люди не хотят читать что-то и не хотят развиваться, но при этом даже еще и не верят Пете, что и как надо делать.
Напомню начало нашего разговора: программирование — это такая странная отрасль, где сидение за компьютером не говорит даже, что программист двигается в нужном направлении. Решая задачу, программист может как решать, так и двигаться в совершенно другую сторону. Настоящий Петя всегда болеет за проект. Это самурай проекта. Не людей, не начальства. И если Петя видит, что бездарности просто тупо на лишний год могут затянуть проект (а может вообще не закончат, бывало и такое), то он конечно будет конфликтовать. Лучше раз поспорить, чем месяцы потерять, делая какую-то ерунду.
Все грабли и вся ерунда происходит потому, что 90 процентов программистов (из головы цифра) даже на половину не программисты по знаниям и опыту. Все ошибки, которые я вообще в жизни видел — это непонимание проектирования, чрезмерный оверинжениринг. Чрезмерный — просто не то слово. То, что можно сделать кратко и лаконично — вырастает в тысячи и тысячи строк, в сотни багов. Каждая лишняя строка рождает снова дополнительный код.
Так что возможно, Петя и прав. Как минимум, если у вас есть статистика, что он делает код быстрее и надежнее — надо этого человека слушать. Авось что-то умное узнаете. Ведь ничего ж просто так не бывает. Значит у него есть знания, которые надо перенять.
На счет в три раза больше зп — это вы правильно сказали. Хотя и не совсем. Любой настоящий Петя может и просто так уйти и несколько лет не работать (деньги у него и так есть). Или на вольные хлеба. «Некуда идти» — никогда не было аргументом. Некуда идти тем, кто зря зарплату получает. Вот эти будут бояться, что только здесь им дают деньги, а в другом месте не дадут вообще.
Так я ж о том как раз и говорю — выгодно держать именно Петь (зарплата не в три раза больше, а производительность может быть в десятки раз выше).
Заговоров, конечно, я мало встречал. Тут дело не в заговорах, а в том, что даже не сговариваясь, бездарность будет спорить с Петей или Петя с ним. Есть два варианта для бездарности (зря конечно я такое слово употребляю, все когда-то были неопытными) — это поднимать свой уровень, читать и учиться, а также слушать Петю, чтобы понять, почему же у него так хорошо всё получается. Второй — не быть женатым на работе, иметь личную жизнь, ездить на курорты, играть по вечерам в компьютерные игры — в общем делать всё, что угодно, только не развиваться в своей профессии. И если приплюсовать еще большое ЧСВ, когда такая бездарность в жизни книгу в руки не брала, и вдруг начинает себя считать профи и начинает не только не соглашаться с Петей, но уже и учить его — конфликты неизбежны.
Кстати, я когда-то работал с такой «звездой». Человек очень конфликтный был. И спорили мы с ним часто. Иногда он глупости говорил. Не очень хорошо разбирался в математике. Но что у него не отнять — отличный программист. И я сумел перенять его опыт, за что ему благодарен.
Банально, если разница в знаниях очень большая, то конфликты неизбежны, если люди не хотят читать что-то и не хотят развиваться, но при этом даже еще и не верят Пете, что и как надо делать.
Напомню начало нашего разговора: программирование — это такая странная отрасль, где сидение за компьютером не говорит даже, что программист двигается в нужном направлении. Решая задачу, программист может как решать, так и двигаться в совершенно другую сторону. Настоящий Петя всегда болеет за проект. Это самурай проекта. Не людей, не начальства. И если Петя видит, что бездарности просто тупо на лишний год могут затянуть проект (а может вообще не закончат, бывало и такое), то он конечно будет конфликтовать. Лучше раз поспорить, чем месяцы потерять, делая какую-то ерунду.
Все грабли и вся ерунда происходит потому, что 90 процентов программистов (из головы цифра) даже на половину не программисты по знаниям и опыту. Все ошибки, которые я вообще в жизни видел — это непонимание проектирования, чрезмерный оверинжениринг. Чрезмерный — просто не то слово. То, что можно сделать кратко и лаконично — вырастает в тысячи и тысячи строк, в сотни багов. Каждая лишняя строка рождает снова дополнительный код.
Так что возможно, Петя и прав. Как минимум, если у вас есть статистика, что он делает код быстрее и надежнее — надо этого человека слушать. Авось что-то умное узнаете. Ведь ничего ж просто так не бывает. Значит у него есть знания, которые надо перенять.
На счет в три раза больше зп — это вы правильно сказали. Хотя и не совсем. Любой настоящий Петя может и просто так уйти и несколько лет не работать (деньги у него и так есть). Или на вольные хлеба. «Некуда идти» — никогда не было аргументом. Некуда идти тем, кто зря зарплату получает. Вот эти будут бояться, что только здесь им дают деньги, а в другом месте не дадут вообще.
Так я ж о том как раз и говорю — выгодно держать именно Петь (зарплата не в три раза больше, а производительность может быть в десятки раз выше).
Заговоров, конечно, я мало встречал. Тут дело не в заговорах, а в том, что даже не сговариваясь, бездарность будет спорить с Петей или Петя с ним. Есть два варианта для бездарности (зря конечно я такое слово употребляю, все когда-то были неопытными) — это поднимать свой уровень, читать и учиться, а также слушать Петю, чтобы понять, почему же у него так хорошо всё получается. Второй — не быть женатым на работе, иметь личную жизнь, ездить на курорты, играть по вечерам в компьютерные игры — в общем делать всё, что угодно, только не развиваться в своей профессии. И если приплюсовать еще большое ЧСВ, когда такая бездарность в жизни книгу в руки не брала, и вдруг начинает себя считать профи и начинает не только не соглашаться с Петей, но уже и учить его — конфликты неизбежны.
Кстати, я когда-то работал с такой «звездой». Человек очень конфликтный был. И спорили мы с ним часто. Иногда он глупости говорил. Не очень хорошо разбирался в математике. Но что у него не отнять — отличный программист. И я сумел перенять его опыт, за что ему благодарен.
Вашу точку зрения я понял, нового я Вам ничего не скажу, так как у Вас есть свой жизненный опыт в роли Пети и как все работает Вы уже прекрасно знаете :-)
Может быть рано или поздно Вам повезет и вы найдете компанию где воплотятся все Ваши пожелания, скорей всего это будет Ваша собственная компания, но чем чёрт не шутит.
На счет коллектива состоящего их Петь… если все Пети того типажа что вы описали то они плохо работают с коллегами, но с Петями они, зачастую, работают еще хуже, к сожалению для того чтоб их научить работать вместе должна быть сильнейшая мотивация как руководства так и самих Петь.
На сим разрешите откланяться, ветка получилась уже очень длинная и мы уже заходим на третий круг и начинаем повторяться.
Удачного Нового Года.
Может быть рано или поздно Вам повезет и вы найдете компанию где воплотятся все Ваши пожелания, скорей всего это будет Ваша собственная компания, но чем чёрт не шутит.
На счет коллектива состоящего их Петь… если все Пети того типажа что вы описали то они плохо работают с коллегами, но с Петями они, зачастую, работают еще хуже, к сожалению для того чтоб их научить работать вместе должна быть сильнейшая мотивация как руководства так и самих Петь.
На сим разрешите откланяться, ветка получилась уже очень длинная и мы уже заходим на третий круг и начинаем повторяться.
Удачного Нового Года.
Я не считаю себя конфликтным человеком. Но иногда бывает.
Оно и так всё воплотилось, на этой работе хорошо меня ценят. Потому что статистика серьезная по выполненным задачам и их сложности.
Работать с неопытными коллегами тяжело. Все они хорошие люди и мы вроде ладим неплохо. Но без конфликтов не было бы развития. Уже многие поменяли свою точку зрения и видно, как буквально за год начали чуть правильнее мыслить.
Если у вас есть такой пусть конфликтный Петя, то его потеря может быть дорогой. Даже не потому, что некому будет закрыть дыру, когда надо сделать что-то быстро. А в том, что он может посоветовать как развивать проект оптимальным образом (даже не участвуя в нем) или справиться с нестандартной ситуацией. Другие будут просто эффективнее работать. Ну и незаметно у него учиться. Через пару лет может все будут как Пети.
Сложный вопрос, потому что конфликтные люди никому не нравятся. Я возможно, себе представляю другого Петю, а у вас конкретный, с которым невозможно работать.
И вас с наступающим!
Оно и так всё воплотилось, на этой работе хорошо меня ценят. Потому что статистика серьезная по выполненным задачам и их сложности.
Работать с неопытными коллегами тяжело. Все они хорошие люди и мы вроде ладим неплохо. Но без конфликтов не было бы развития. Уже многие поменяли свою точку зрения и видно, как буквально за год начали чуть правильнее мыслить.
Если у вас есть такой пусть конфликтный Петя, то его потеря может быть дорогой. Даже не потому, что некому будет закрыть дыру, когда надо сделать что-то быстро. А в том, что он может посоветовать как развивать проект оптимальным образом (даже не участвуя в нем) или справиться с нестандартной ситуацией. Другие будут просто эффективнее работать. Ну и незаметно у него учиться. Через пару лет может все будут как Пети.
Сложный вопрос, потому что конфликтные люди никому не нравятся. Я возможно, себе представляю другого Петю, а у вас конкретный, с которым невозможно работать.
И вас с наступающим!
К слову о парном программировании… :D
Очень многие вещи в точку. Непонимание сути вещей и увлечение внешней стороной вопроса мне кажется — наиболее распространенная беда.
Вот вам ещё седьмой способ, самый надёжный. Использование кривого ПО. То есть менеджер говорит: «Я тут пообщался с сэйлзом компании H, у них такие классные графики! А ещё он сказал что его программа специально под agile написана. С понедельника переходим на H!» А в понедельник оказывается, что программа H написана только под Win, зависит от последних .Net апдейтов, тормозит при одновременной работе нескольких пользователей и периодически падает. А ещё иногда теряет внесённые изменения. И вся команда тратит безумное количество времени на эту тулзу. А кое-кто уже написал скрипт для работы с ней (через эмуляцию кликов и клавиш, конечно же, ведь открытого API у чудо-программы нет). И всё это вместо работы.
Самый надёжный способ убить agile!
Самый надёжный способ убить agile!
Я может быть что — то не понимаю, но пожалуйста, объясните: а зачем Пете agile если он и так крайне эффективен и может делать работу пол команды? И разве не рискованно то, что если его начнут сильно донимать с ежедневными рассказами джуниоров о их приключениях — он будет искать новое место? А может он вообще заслуживает отдельного подхода?
Петя не масштабируем, к сожалению, до тех пора не изобрели клонирования тела и знаний. Все хорошо пока он может в одного тянуть проект, в таком случае ему действиетельно Agile ни к чему, важен результат. Но как только Пети станет мало начинаются сложности и приходится платить свою цену за фреймворк в котором буду работать люди.
Точно не заслуживает. Задача менеджера — сделать процесс разработки не зависящим от людей на местах.
Вложу свои 5 копеек.
Тут очень многие пишут о том, что их утомляют ежедневные митинги и куча отчётности.
Приведу в пример нашу команду. Нет, мы не исповедуем Agile на 100%, но за пару месяцев у нас выработалась своя микрометодика.
Во-первых не стоит забывать, что Agile работает в командах по 5-8 человек. Это оптимальные цифры. Во-вторых, Agile — всего лишь инструмент коммуникации.
Когда мы проводим утренний митинг, мне на самом деле интересно, чем занимаются другие участники команды. И я могу внести ряд своих предложений в текущий план. А самое главное — я знаю кому я могу помочь здесь и сейчас поделившись своими знаниями (например, интересным трюком в CSS или какими-то познаниями в JavaScript) с остальными участниками команды, у которых в знакомых мне областях возникают сложности.
Это очень круто. Раньше, в других компаниях, использовавших классические методики управления, я не чувствовал себя настолько нужным, как чувствую сейчас.
Кроме того, всем и каждому видна динамика всего проекта в целом. Каждый участник команды знает, когда можно немного расслабиться и навернуть немножко «сахара» в проекте, а когда сжать сфинктер и потушить разгорающийся пожар.
Тут очень многие пишут о том, что их утомляют ежедневные митинги и куча отчётности.
Приведу в пример нашу команду. Нет, мы не исповедуем Agile на 100%, но за пару месяцев у нас выработалась своя микрометодика.
Во-первых не стоит забывать, что Agile работает в командах по 5-8 человек. Это оптимальные цифры. Во-вторых, Agile — всего лишь инструмент коммуникации.
Когда мы проводим утренний митинг, мне на самом деле интересно, чем занимаются другие участники команды. И я могу внести ряд своих предложений в текущий план. А самое главное — я знаю кому я могу помочь здесь и сейчас поделившись своими знаниями (например, интересным трюком в CSS или какими-то познаниями в JavaScript) с остальными участниками команды, у которых в знакомых мне областях возникают сложности.
Это очень круто. Раньше, в других компаниях, использовавших классические методики управления, я не чувствовал себя настолько нужным, как чувствую сейчас.
Кроме того, всем и каждому видна динамика всего проекта в целом. Каждый участник команды знает, когда можно немного расслабиться и навернуть немножко «сахара» в проекте, а когда сжать сфинктер и потушить разгорающийся пожар.
Я знаю только одну проблему к внедрению Agile, но, она всегда оказывается ключевой. Это люди. Да, те самые люди, которые входят в команду. Если вы взяли 5-8 «рекомендованных» членов команды, вы внедрили все «рекомендованные» практики, но если этим людям оно все не надо, ваши аджайлы, ваши релизы, а на запуск проекта им всем похбоку, то никакие трюки не помогут. Если у вас есть команда, которая не шарахается от страшеых слов типа TDD, привыкли, что за ними проверит тестировщик, и благодарны ему за каждый найденный баг, у вас развертывание релиза происходит за три клика, то Agile — ваш выбор, все у вас будет хорошо. В остальных случаях, записки камикадзе вам в помощь.
Прочитав статью у меня сложилось впечатление, что суть agile состоит в том, чтобы сотрудники постоянно что-нибудь говорили?
Как это было у нас:
1. поделили сотрудников компании на небольшие тимы.
2. сказали, что для каждая команда будет сама для себя определять как ей работать с наибольшей эффективностью.
3. потом убрали все права в Jira.
4. на митинге ретроспективы сросили, что нам хотелось бы поменять в Jira. Мы попросили возможность хотя бы переназначать задачи друг на друга. Нам отказали и спросили или есть еще пожелания. Естественно, что пожеланий у нас больше не было.
5. в какой то момент мы в команде решили, что использовать git намного эффективнее, чем svn. несколько месяцев получали бенефиты.
6. пришел главный менеджер и сказал, что у компании есть полиси, которые нужно выполнять и нечего тут использовать свои инструментарии, даже если она помогают нам повышать эффективность. мы ему заметили, что нигде в полиси не указан svn как единый правильный репозиторий для компании. результат: главный менеджер написал полиси, в котором указал, что свн — единый правильный репо.
Вывод: если смешивать Agile с водопадной моделью, то минусы обоих подходов суммируются, а плюсы не добавляются.
Хотя, возможно, что так прозошло только в нашей компании.
1. поделили сотрудников компании на небольшие тимы.
2. сказали, что для каждая команда будет сама для себя определять как ей работать с наибольшей эффективностью.
3. потом убрали все права в Jira.
4. на митинге ретроспективы сросили, что нам хотелось бы поменять в Jira. Мы попросили возможность хотя бы переназначать задачи друг на друга. Нам отказали и спросили или есть еще пожелания. Естественно, что пожеланий у нас больше не было.
5. в какой то момент мы в команде решили, что использовать git намного эффективнее, чем svn. несколько месяцев получали бенефиты.
6. пришел главный менеджер и сказал, что у компании есть полиси, которые нужно выполнять и нечего тут использовать свои инструментарии, даже если она помогают нам повышать эффективность. мы ему заметили, что нигде в полиси не указан svn как единый правильный репозиторий для компании. результат: главный менеджер написал полиси, в котором указал, что свн — единый правильный репо.
Вывод: если смешивать Agile с водопадной моделью, то минусы обоих подходов суммируются, а плюсы не добавляются.
Хотя, возможно, что так прозошло только в нашей компании.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
6 Способов убить Agile