Пока что мы с Иваном главные технические и управленческие авторитеты, но это ненадолго. Ребята стремительно растут в техническом плане, мы со своей стороны стараемся поддерживать уровень осмысленности принимаемых ими решений. Мы по понятным причинам в техническом плане уже не растем и скоро они нас обгонят :-)
Вообще — в каждой технологии должен быть признанный гуру. Причем ни в коем случае не менеджер. К этому гуру народ как раз-таки ходит за советом и уже одобренное решение несет менеджеру. Конечно, менеджеры должны авторитет гуру тоже признавать. Я видела такое на своей последней наемной работе, это работает.
Да, я никак не работаю с этими рисками в том смысле, который имеете в виду Вы. Я не рисую диаграммы и не оцениваю вероятности. И не потому, что не знаю о том, что это делают другие компании. Я читала книгу Ди Марко и Листера Вальсируя с медведями, на AgileCamp с удовольствием принимала участие в тренинге от хабраюзера blv, и т.д.
Я осознанно приняла решение, что в наших условиях все это излишне. Все, что я могу сделать, это не покупать лексусы за счет недоплаченных зарплат и быть своей команде другом, а не цербером. Пока что это работает. К сожалению, метод слишком индивидуален и в качестве общего рецепта не годится (хотя человееское отношение к команде вряд ли будет вредным советом :-)).
Мы стараемся убеждать, что на проектах в продакшене менять движки можно только если есть очень-очень веские причины. И это все в команде понимают. Холивар и «я тут вчера статью прочитал, Maven лучше» — не аргумент. Недавно перевели, кстати, как раз — но по веским причинам. Переводили проект со Spring 2.5 на Spring 3.0, пришлось и на Maven заодно. Но тут вместе все просчитали, прикинули, согласовали с заказчиком (!) — и тогда уже сделали.
Пока что за 2 года с проблемой не столкнулись. Все, кто ушел, либо не подходили по духу, либо сильно заранее предупреждали и уходили, никого не подставляя. Последние, кстати, периодически заходят в гости, кто в городе, и остаются в общих чатах команды (кроме проектных). Дают советы по вопросам своей компетенции всем сотрудникам, даже тем, с кем не успели познакомиться лично.
Конечно, я видела и другие случаи, но чаще всего, там были все-таки внутренние проблемы того или иного сорта.
Риск есть для меня в двух случаях: мы накосячим или кто-то резко начнет бомбардировать ребят с предложением зарплаты в 2-3 раза выше. Со вторым мы вряд ли сможем что-либо сделать, кроме повышения зарплат. Это по сути форс-мажор, как нынче со «Сбербанк-технологиями» в Java-мире.
Скажу совсем крамольную мысль — мы не расстроимся, если все наши ребята разойдутся по крутым конторам и от нашей ничего не останется. Мы будем считать свою миссию выполненной в каком-то смысле, да и сами не пропадем :-)
1) Ну это нормально, из 100 идей в R&D только одна может быть гениальной, но я имела в виду совсем другое.
2) Так и мы не занимаемся бесполезными горячими спорами. У меня к счастью нет проблемы отсеивания дурацких идей джуниоров, поэтому ничего не подскажу.
На нашем сайте написано: «У нас высокие требования к людям. При этом ваше отношение к жизни, работе и обучению значат для нас больше, чем ваши текущие знания.» И это не для красного словца. Если брать в команду только тех, с кем можно пойти в разведку, просто не возникает пустых споров ни о чем на ровном месте. Почему-то все понимают, когда надо лезть с идеей, а когда нет. Адекватно реагируют на критику и слушают аргументы друг друга.
В уже рекомендованной выше книге «От хорошего к великому» есть совет: «Сначала наберите в команду звезд, а потом придумывайте стратегию развития вместе с ними», есть конкретный пример, как это работает. В правильно подобранной команде редко возникают такие споры. Вот свеженький пост в тему.
Вы не занимаетесь тимбилдингами для галочки — другие занимаются, таких масса, я своими глазами наблюдала и участвовала со стороны развлекаемых.
Хочется верить, что это больше, чем просто дань моде. Из этих 30% хорошо если половина доучится и хорошо, если из той половины четверть вырастет в высококвалифицированных специалистов.
Ну вообще. отпуска неожиданными бывают редко. Планируем так, чтобы вся проектная команда не уходила в отпуск одновременно. С этой целью, например, супругов стараюсь по разным командам разводить, но не всегда получается :-)
Да, в маленькой команде риски выше. Но в маленькой команде проще увидеть недовольство и вовремя поговорить с человеком, выяснить что не так и разрешить проблему, которая мешает ему остаться в команде. Опять же человеческое отношение к сотрудникам позволяет не получать неожиданных заявлений на стол. Все, кто уходил, уходили так, чтобы никого не подставить. Как ты к людям, так и они к тебе.
В маленькой команде семейного типа люди редко берут больничный из-за легкого насморка (как часто делают в больших бюрократически раздутых конторах). Они остаются дома, но работают оттуда, чтобы никого не подводить, если позволяет самочувствие.
Я не сказала, что наша мечта подходит всем и каждому. Да, в большой компании разработчику невозможно знать все тонкости бизнеса клиента. Этим занимается аналитик. Но:
1) Бывают проекты, направленные на массового потребителя, каковым разработчик запросто может себя представить. Более того — лучше, если он будет это делать и смотреть на то, что делает команда, глазами пользователя — хотя бы иногда. А еще есть замечательный совет от Джоэля Спольски: «Ешьте свою собачью еду», т.е. пользуйтесь сами своим ПО, начиная с ранней альфы, и тогда большая часть багов и просто неудобных интерфейсных решений до пользователей не дойдет (к сожалению, точной ссылки сходу не нашлось, но эта статья есть в книге «Джоэль о программировании»).
2) Даже если проект очень сложен и в тонкостях разбираются аналитики, разработчик должен чувствовать, что он делает что-то нужное и полезное. В идеале — еще и понимать, кому конкретно. Сделать так, чтобы разработчик не лез ко всем подряд с вопросами, но ощущал свою полезность в масштабе Вселенной — искусство менеджера. Если менеджер поднимает лапки и говорит, что ему проще всех послать, чем каждому объяснять, что и зачем он делает, то менеджеру надо поискать другую работу (это только мое мнение, не хочу никого обидеть). Менеджер — это лидер. Если он не имеет авторитета в коллективе и не обладает определенной харизмой — он не станет хорошим менеджером и проекты под его руководством не придут к успеху.
Резюмирую — не обязательно каждому знать все, но каждый должен знать достаточно, чтобы иметь ВНУТРЕННЮЮ мотивацию. Никакие танцы вокруг костра на тимбилдинге и крики «мы лучшие!!!» в толпу — не помогут. Конечно, это требует времени менеджера. И лучше его потратить на это, чем на бесполезные тимбилдинги для галочки.
Мой модуль для экологов тоже до сих пор работает, никто им не занимается. Я уходила в декрет в 2006-м, с тех пор я его не правила. У них очень медленно меняются процессы, поэтому изменений софта могут не требовать годами :-)
А еще в 2006-м их начальница мне сказала: хватит все автоматизировать, а то вместо отдела оставят одного человека, уймись!
Команда есть, которую прокачиваем технически всеми возможными способами и интересные проекты, на которых стараемся работать по этой схеме. Как-то так :-)
Да-да-да, сидеть рядом с пользователем и научиться делать то, что делает он, а потом понять как это автоматизировать.
Меня первый раз пробило, когда мне тетеньки-экологи показали, как они делают расчет в экселе, а потом на моей форме :-) Разница во времени — 3-5 раз. Не в мою пользу. В итоге я им сделала поведение формы в браузере с точки зрения клавиш — как в экселе, чтобы никакой мыши, переход по Enter и т.д. В итоге они смогли использовать свою моторную память и были довольны.
Можно пытаться устроить в рамках большой компании небольшие проектные команды, полностью автономные. Которым выделяется бюджет и они делают проект полностью своими силами. Внутреннее предпринимательство по сути.
Вообще — в каждой технологии должен быть признанный гуру. Причем ни в коем случае не менеджер. К этому гуру народ как раз-таки ходит за советом и уже одобренное решение несет менеджеру. Конечно, менеджеры должны авторитет гуру тоже признавать. Я видела такое на своей последней наемной работе, это работает.
Я осознанно приняла решение, что в наших условиях все это излишне. Все, что я могу сделать, это не покупать лексусы за счет недоплаченных зарплат и быть своей команде другом, а не цербером. Пока что это работает. К сожалению, метод слишком индивидуален и в качестве общего рецепта не годится (хотя человееское отношение к команде вряд ли будет вредным советом :-)).
Конечно, я видела и другие случаи, но чаще всего, там были все-таки внутренние проблемы того или иного сорта.
Риск есть для меня в двух случаях: мы накосячим или кто-то резко начнет бомбардировать ребят с предложением зарплаты в 2-3 раза выше. Со вторым мы вряд ли сможем что-либо сделать, кроме повышения зарплат. Это по сути форс-мажор, как нынче со «Сбербанк-технологиями» в Java-мире.
Скажу совсем крамольную мысль — мы не расстроимся, если все наши ребята разойдутся по крутым конторам и от нашей ничего не останется. Мы будем считать свою миссию выполненной в каком-то смысле, да и сами не пропадем :-)
2) Так и мы не занимаемся бесполезными горячими спорами. У меня к счастью нет проблемы отсеивания дурацких идей джуниоров, поэтому ничего не подскажу.
На нашем сайте написано: «У нас высокие требования к людям. При этом ваше отношение к жизни, работе и обучению значат для нас больше, чем ваши текущие знания.» И это не для красного словца. Если брать в команду только тех, с кем можно пойти в разведку, просто не возникает пустых споров ни о чем на ровном месте. Почему-то все понимают, когда надо лезть с идеей, а когда нет. Адекватно реагируют на критику и слушают аргументы друг друга.
В уже рекомендованной выше книге «От хорошего к великому» есть совет: «Сначала наберите в команду звезд, а потом придумывайте стратегию развития вместе с ними», есть конкретный пример, как это работает. В правильно подобранной команде редко возникают такие споры. Вот свеженький пост в тему.
Вы не занимаетесь тимбилдингами для галочки — другие занимаются, таких масса, я своими глазами наблюдала и участвовала со стороны развлекаемых.
Да, в маленькой команде риски выше. Но в маленькой команде проще увидеть недовольство и вовремя поговорить с человеком, выяснить что не так и разрешить проблему, которая мешает ему остаться в команде. Опять же человеческое отношение к сотрудникам позволяет не получать неожиданных заявлений на стол. Все, кто уходил, уходили так, чтобы никого не подставить. Как ты к людям, так и они к тебе.
В маленькой команде семейного типа люди редко берут больничный из-за легкого насморка (как часто делают в больших бюрократически раздутых конторах). Они остаются дома, но работают оттуда, чтобы никого не подводить, если позволяет самочувствие.
1) Бывают проекты, направленные на массового потребителя, каковым разработчик запросто может себя представить. Более того — лучше, если он будет это делать и смотреть на то, что делает команда, глазами пользователя — хотя бы иногда. А еще есть замечательный совет от Джоэля Спольски: «Ешьте свою собачью еду», т.е. пользуйтесь сами своим ПО, начиная с ранней альфы, и тогда большая часть багов и просто неудобных интерфейсных решений до пользователей не дойдет (к сожалению, точной ссылки сходу не нашлось, но эта статья есть в книге «Джоэль о программировании»).
2) Даже если проект очень сложен и в тонкостях разбираются аналитики, разработчик должен чувствовать, что он делает что-то нужное и полезное. В идеале — еще и понимать, кому конкретно. Сделать так, чтобы разработчик не лез ко всем подряд с вопросами, но ощущал свою полезность в масштабе Вселенной — искусство менеджера. Если менеджер поднимает лапки и говорит, что ему проще всех послать, чем каждому объяснять, что и зачем он делает, то менеджеру надо поискать другую работу (это только мое мнение, не хочу никого обидеть). Менеджер — это лидер. Если он не имеет авторитета в коллективе и не обладает определенной харизмой — он не станет хорошим менеджером и проекты под его руководством не придут к успеху.
Резюмирую — не обязательно каждому знать все, но каждый должен знать достаточно, чтобы иметь ВНУТРЕННЮЮ мотивацию. Никакие танцы вокруг костра на тимбилдинге и крики «мы лучшие!!!» в толпу — не помогут. Конечно, это требует времени менеджера. И лучше его потратить на это, чем на бесполезные тимбилдинги для галочки.
А еще в 2006-м их начальница мне сказала: хватит все автоматизировать, а то вместо отдела оставят одного человека, уймись!
Меня первый раз пробило, когда мне тетеньки-экологи показали, как они делают расчет в экселе, а потом на моей форме :-) Разница во времени — 3-5 раз. Не в мою пользу. В итоге я им сделала поведение формы в браузере с точки зрения клавиш — как в экселе, чтобы никакой мыши, переход по Enter и т.д. В итоге они смогли использовать свою моторную память и были довольны.
Но тут нужна огромная адекватность руководства.