Comments 84
Я всё прочитал и хотел бы узнать, где ещё можно посмотреть ваши фотографии?)
Черт, я хотела закрыть тему девушкой с баяном :-)
Спасибо, что осилили, судя по минусам — не всем это удалось.
Спасибо, что осилили, судя по минусам — не всем это удалось.
Нет, нет, это очень важно) На моей памяти вы первая симпатичная девушка программист)
По поводу объема: вы не родственника Льва Толстого?)
По поводу минусов: причина явно в половой дискриминации. Если бы вы были парнем, то результат был бы другим)
По поводу объема: вы не родственника Льва Толстого?)
По поводу минусов: причина явно в половой дискриминации. Если бы вы были парнем, то результат был бы другим)
Симпатичных девушек-программистов больше, чем вы думаете. У меня таковых двое работает.
Изначально я хотела отделить то, что желательно прочитать, от баек. Но попросили убрать форматирование.
Я привыкла к такой реакции :-) Не обращаю внимания.
Изначально я хотела отделить то, что желательно прочитать, от баек. Но попросили убрать форматирование.
Я привыкла к такой реакции :-) Не обращаю внимания.
Ага, отлично) Тогда ваше фото и их тоже, будьте добры…
Хмм… форматирование убрать, байки оставить?
Вы привыкли быть белой вороной?) Моя знакомая говорит, что нужно быть клёвой белой вороной.
Хмм… форматирование убрать, байки оставить?
Вы привыкли быть белой вороной?) Моя знакомая говорит, что нужно быть клёвой белой вороной.
Чувак, обычный инструментарий пикап-мастера на девушек-программистов не распространяются ;))
* не срабатывает т.е.
AnnieOmsk — не девушка, а женщина в самом соку *облизнулся плотоядно*) Я уверен, что у неё достаточно опыта, чтобы почувствовать мой потенциал и ответить взаимностью)
Эм, ну ок, желаю выдержать бенчмарк и все такое =))
Меня терзают смутные сомнения, что вы идиот.
Один запрос в гугле выдал и фотографии, и семейный статус.
Так как я сегодня добрый, подготовил для вас небольшой перфоманс.
lmgtfy.com/?q=%D0%90%D0%BD%D0%BD%D0%B0+%D0%A2%D0%B0%D1%80%D0%B0%D1%81%D0%B5%D0%BD%D0%BA%D0%BE+%D0%BE%D0%BC%D1%81%D0%BA
Один запрос в гугле выдал и фотографии, и семейный статус.
Так как я сегодня добрый, подготовил для вас небольшой перфоманс.
lmgtfy.com/?q=%D0%90%D0%BD%D0%BD%D0%B0+%D0%A2%D0%B0%D1%80%D0%B0%D1%81%D0%B5%D0%BD%D0%BA%D0%BE+%D0%BE%D0%BC%D1%81%D0%BA
Ого, спасибо, давненько не гуглила про себя. Увидела вот такое: moikrieg.ru/users/tarasenkoanna2/, посмеялась :-)
Гугл меня подставил: секретарь омских «единороссов» — это не я! :-)
Я взял большую часть минусов на себя — уже за это можно предоставить фото, Анна!;)
По-моему гугл все отлично предоставляет :-)
Практикуйтесь чаще в перфомансах — они выглядят у вас нелепо и смешно)
А давайте не будем разводить личные оскорбления? Ей-богу оно того не стоит. Не портите каменты, пожалуйста :-)
Я что, ошибся вкладкой и читаю Мамбу, а не Хабр? О_о
Зашел в комментарии к статье, написанной девушкой.
Первый комментарий — просьба показатьсиськи фотку.
Все, как положено.
От себя автору — спасибо, очень занимательно. Осилил половину, завтра дочитаю.
Первый комментарий — просьба показать
Все, как положено.
От себя автору — спасибо, очень занимательно. Осилил половину, завтра дочитаю.
Очень долгое чтиво, не так просто за раз осилить.
Всё вроде и понятно, но не всегда получается именно так, как должно было бы быть в идеале. В этом плане статья полезная для чтения всеми, кто связан с разработкой, чтобы оглядеться по сторонам, и оценить по-новому текущую ситуацию, всегда есть куда улучшаться.
Но самая главная мысль — разработка должна приносить удовольствие, это бесспорно.
Всё вроде и понятно, но не всегда получается именно так, как должно было бы быть в идеале. В этом плане статья полезная для чтения всеми, кто связан с разработкой, чтобы оглядеться по сторонам, и оценить по-новому текущую ситуацию, всегда есть куда улучшаться.
Но самая главная мысль — разработка должна приносить удовольствие, это бесспорно.
Очень интересно! Спасибо, что излили изложили личный опыт.
Вы, Анна, судя по всему, из неугомонных))
Безобидная обоснованная инициатива снизу зачастую воспринимается вышестоящими как «лезет не в свою работу, когда своей полно» и, наверное даже, «тычет в мои ошибки, метит на мое место».
Стремление внести вклад в общее дело (в вакансиях приветствуется, на собеседованиях оговаривается) на деле оборачивается назреванием конфликта (один терпит «тупого» сумасброда, другой «шибко умного» выскочку).
Как итог — увольнение, [другая контора,] «что-то свое» (конкуренция, демпинг… поиск счастья..)
Хотя, большинству (из нас))) работать «на дядю» — ноу проблем. Проблема — «невесть откуда» возникающее желание «бороться за здравый смысл» даже при хорошей зарплате.
Вы, Анна, судя по всему, из неугомонных))
Безобидная обоснованная инициатива снизу зачастую воспринимается вышестоящими как «лезет не в свою работу, когда своей полно» и, наверное даже, «тычет в мои ошибки, метит на мое место».
Стремление внести вклад в общее дело (в вакансиях приветствуется, на собеседованиях оговаривается) на деле оборачивается назреванием конфликта (один терпит «тупого» сумасброда, другой «шибко умного» выскочку).
Как итог — увольнение, [другая контора,] «что-то свое» (конкуренция, демпинг… поиск счастья..)
Хотя, большинству (из нас))) работать «на дядю» — ноу проблем. Проблема — «невесть откуда» возникающее желание «бороться за здравый смысл» даже при хорошей зарплате.
Ну меня «стабильность» и деньги уже давно не мотивируют. «Я не хочу ничего решать, я хочу просто писать код» — тоже не наш принцип. Стараемся наносить непоправимую пользу, как говорит дядя Слава Панкратов, по мере сил. И только в этом я вижу смысл нашей работы.
Тема промышленных методов не раскрыта.
Статья только про счастье, и мелкую разработку.
Статья только про счастье, и мелкую разработку.
Простите, что влезу, но сколько времени по вашему должно занимать обсуждение всех инициатив? Допустим у меня команда разработки 20 человек, все такие инициативные с кучей идей и каждый ходит к PM и двигает свои идеи, некоторые из них противоречат идеям других разработчиков, или как обычно бывает, разработчики не владеют информацией в том же объёме, что ПМ или аналитик, просто потому, что у них нет столько времени на изучение проекта.
Знаете, мне как руководителю, проще запретить инициативы от сотрудников, пусть даже мы на этом потеряем 5% скорости или качества, чем дам возможность вынести мозг человеку отвечающему за весь проект, потому что все эти «общие обсуждения», общее владение знаниями и т.д. может снизить производительность команды процентов на 30%.
Я не говорю, что нужно всё запрещать и делать из людей безинициативных роботов, но нужно искать компромисс прежде всего.
Знаете, мне как руководителю, проще запретить инициативы от сотрудников, пусть даже мы на этом потеряем 5% скорости или качества, чем дам возможность вынести мозг человеку отвечающему за весь проект, потому что все эти «общие обсуждения», общее владение знаниями и т.д. может снизить производительность команды процентов на 30%.
Я не говорю, что нужно всё запрещать и делать из людей безинициативных роботов, но нужно искать компромисс прежде всего.
Я не сказала, что наша мечта подходит всем и каждому. Да, в большой компании разработчику невозможно знать все тонкости бизнеса клиента. Этим занимается аналитик. Но:
1) Бывают проекты, направленные на массового потребителя, каковым разработчик запросто может себя представить. Более того — лучше, если он будет это делать и смотреть на то, что делает команда, глазами пользователя — хотя бы иногда. А еще есть замечательный совет от Джоэля Спольски: «Ешьте свою собачью еду», т.е. пользуйтесь сами своим ПО, начиная с ранней альфы, и тогда большая часть багов и просто неудобных интерфейсных решений до пользователей не дойдет (к сожалению, точной ссылки сходу не нашлось, но эта статья есть в книге «Джоэль о программировании»).
2) Даже если проект очень сложен и в тонкостях разбираются аналитики, разработчик должен чувствовать, что он делает что-то нужное и полезное. В идеале — еще и понимать, кому конкретно. Сделать так, чтобы разработчик не лез ко всем подряд с вопросами, но ощущал свою полезность в масштабе Вселенной — искусство менеджера. Если менеджер поднимает лапки и говорит, что ему проще всех послать, чем каждому объяснять, что и зачем он делает, то менеджеру надо поискать другую работу (это только мое мнение, не хочу никого обидеть). Менеджер — это лидер. Если он не имеет авторитета в коллективе и не обладает определенной харизмой — он не станет хорошим менеджером и проекты под его руководством не придут к успеху.
Резюмирую — не обязательно каждому знать все, но каждый должен знать достаточно, чтобы иметь ВНУТРЕННЮЮ мотивацию. Никакие танцы вокруг костра на тимбилдинге и крики «мы лучшие!!!» в толпу — не помогут. Конечно, это требует времени менеджера. И лучше его потратить на это, чем на бесполезные тимбилдинги для галочки.
1) Бывают проекты, направленные на массового потребителя, каковым разработчик запросто может себя представить. Более того — лучше, если он будет это делать и смотреть на то, что делает команда, глазами пользователя — хотя бы иногда. А еще есть замечательный совет от Джоэля Спольски: «Ешьте свою собачью еду», т.е. пользуйтесь сами своим ПО, начиная с ранней альфы, и тогда большая часть багов и просто неудобных интерфейсных решений до пользователей не дойдет (к сожалению, точной ссылки сходу не нашлось, но эта статья есть в книге «Джоэль о программировании»).
2) Даже если проект очень сложен и в тонкостях разбираются аналитики, разработчик должен чувствовать, что он делает что-то нужное и полезное. В идеале — еще и понимать, кому конкретно. Сделать так, чтобы разработчик не лез ко всем подряд с вопросами, но ощущал свою полезность в масштабе Вселенной — искусство менеджера. Если менеджер поднимает лапки и говорит, что ему проще всех послать, чем каждому объяснять, что и зачем он делает, то менеджеру надо поискать другую работу (это только мое мнение, не хочу никого обидеть). Менеджер — это лидер. Если он не имеет авторитета в коллективе и не обладает определенной харизмой — он не станет хорошим менеджером и проекты под его руководством не придут к успеху.
Резюмирую — не обязательно каждому знать все, но каждый должен знать достаточно, чтобы иметь ВНУТРЕННЮЮ мотивацию. Никакие танцы вокруг костра на тимбилдинге и крики «мы лучшие!!!» в толпу — не помогут. Конечно, это требует времени менеджера. И лучше его потратить на это, чем на бесполезные тимбилдинги для галочки.
1) Насколько я знаю, сотрудники MC используют такой подход в R&D подразделениях, но при этом продукты у них получаются как удачные, так и нет.
2) Менеджер лапки не поднимает, а как раз общается со всеми. Я начальник этого менеджера и вижу на что он тратит время, обсуждая с джуниорами, почему их креативные идеи не подходят для текущего проекта. ИМХО, нужно чтобы джуниор шёл к сеньйору, сеньйор к архитектору и т.д. вверх. Чтобы менеджеру доходили только самые проверенные идеи. Да, я понимаю, вы сейчас начнёте говорить, что я создаю бюрократию, но порой для бизнеса в целом это выгоднее, чем тратить время на обсуждения и удовлетворение всех идей сотрудников.
А никто не проводит бесполезные тимблиддинги для галочки. Никто не занимается криками, но при этом никто в кружке в 20 человек не обсуждает новые идеи, создавая горячие споры.
2) Менеджер лапки не поднимает, а как раз общается со всеми. Я начальник этого менеджера и вижу на что он тратит время, обсуждая с джуниорами, почему их креативные идеи не подходят для текущего проекта. ИМХО, нужно чтобы джуниор шёл к сеньйору, сеньйор к архитектору и т.д. вверх. Чтобы менеджеру доходили только самые проверенные идеи. Да, я понимаю, вы сейчас начнёте говорить, что я создаю бюрократию, но порой для бизнеса в целом это выгоднее, чем тратить время на обсуждения и удовлетворение всех идей сотрудников.
А никто не проводит бесполезные тимблиддинги для галочки. Никто не занимается криками, но при этом никто в кружке в 20 человек не обсуждает новые идеи, создавая горячие споры.
1) Ну это нормально, из 100 идей в R&D только одна может быть гениальной, но я имела в виду совсем другое.
2) Так и мы не занимаемся бесполезными горячими спорами. У меня к счастью нет проблемы отсеивания дурацких идей джуниоров, поэтому ничего не подскажу.
На нашем сайте написано: «У нас высокие требования к людям. При этом ваше отношение к жизни, работе и обучению значат для нас больше, чем ваши текущие знания.» И это не для красного словца. Если брать в команду только тех, с кем можно пойти в разведку, просто не возникает пустых споров ни о чем на ровном месте. Почему-то все понимают, когда надо лезть с идеей, а когда нет. Адекватно реагируют на критику и слушают аргументы друг друга.
В уже рекомендованной выше книге «От хорошего к великому» есть совет: «Сначала наберите в команду звезд, а потом придумывайте стратегию развития вместе с ними», есть конкретный пример, как это работает. В правильно подобранной команде редко возникают такие споры. Вот свеженький пост в тему.
Вы не занимаетесь тимбилдингами для галочки — другие занимаются, таких масса, я своими глазами наблюдала и участвовала со стороны развлекаемых.
2) Так и мы не занимаемся бесполезными горячими спорами. У меня к счастью нет проблемы отсеивания дурацких идей джуниоров, поэтому ничего не подскажу.
На нашем сайте написано: «У нас высокие требования к людям. При этом ваше отношение к жизни, работе и обучению значат для нас больше, чем ваши текущие знания.» И это не для красного словца. Если брать в команду только тех, с кем можно пойти в разведку, просто не возникает пустых споров ни о чем на ровном месте. Почему-то все понимают, когда надо лезть с идеей, а когда нет. Адекватно реагируют на критику и слушают аргументы друг друга.
В уже рекомендованной выше книге «От хорошего к великому» есть совет: «Сначала наберите в команду звезд, а потом придумывайте стратегию развития вместе с ними», есть конкретный пример, как это работает. В правильно подобранной команде редко возникают такие споры. Вот свеженький пост в тему.
Вы не занимаетесь тимбилдингами для галочки — другие занимаются, таких масса, я своими глазами наблюдала и участвовала со стороны развлекаемых.
Почему всех инициатив? Бредовые идеи должно быть стыдно выдвигать. Бредовость идей — как термометр профессионализма. Фломастером на стене)).
Времени 3-5-10 минут ёмко (понимая, что менеджер персона занятая) и аргументированно высказаться в свободной речевой манере по пунктам:
1. Какая проблема наблюдается (возможно невидимая не_совсем_специалисту_в_определенной_области менеджеру).
2. Что создает эту проблему.
3. Что можно/нужно сделать.
Обсуждение — в случае, когда менеджеру не совсем ясны технические детали, но без фанатизма.
Вынос на общее обсуждение, когда доводы показались действительно разумными.
Но проблемы обычно такие, что в команде 20+ человек, с менеджерами и руководителями менеджеров, возможно, и не существовали бы))
Времени 3-5-10 минут ёмко (понимая, что менеджер персона занятая) и аргументированно высказаться в свободной речевой манере по пунктам:
1. Какая проблема наблюдается (возможно невидимая не_совсем_специалисту_в_определенной_области менеджеру).
2. Что создает эту проблему.
3. Что можно/нужно сделать.
Обсуждение — в случае, когда менеджеру не совсем ясны технические детали, но без фанатизма.
Вынос на общее обсуждение, когда доводы показались действительно разумными.
Но проблемы обычно такие, что в команде 20+ человек, с менеджерами и руководителями менеджеров, возможно, и не существовали бы))
Примеры из моей практики.
Есть предложение перенести сборку проекта на с Ant на Maven.
Есть идея перенести проект с Hibernate на iBatis
Есть мысль сменить аппликейшен сервер.
Всё аргументированно, с + и -. И что делать ПМу? Если откажешься просто так, то обидятся. Если начнёшь доказывать, что в этом нет смысла, упрёшься в холивар, что ещё хуже и т.д.
Есть предложение перенести сборку проекта на с Ant на Maven.
Есть идея перенести проект с Hibernate на iBatis
Есть мысль сменить аппликейшен сервер.
Всё аргументированно, с + и -. И что делать ПМу? Если откажешься просто так, то обидятся. Если начнёшь доказывать, что в этом нет смысла, упрёшься в холивар, что ещё хуже и т.д.
На мой взгляд, в большой команде должно быть по взрослому и привито корпоративной культурой:
Предлагаешь переход с А на Б — запили (на выходных, на коленке) две системы, нагрузи адекватно текущей специфике, сними характеристики, сравни, оформи отчетик/скриншот. Большой шанс отчету оказаться в кулуарах руководства в качестве козыря (@author Developenko, наш парень!) Никакого дара убеждения, все по специальности, по способностям. Получи за «рацуху» плюс в карму и, впоследствии, в карман. Никого не перепрыгнул, помог всем!
А быть безучастным роботом или праздным холи-воином — не стайл.
Не столько программистский мой опыт это подсказывает, сколько жизненный из других сфер деятельности.
Предлагаешь переход с А на Б — запили (на выходных, на коленке) две системы, нагрузи адекватно текущей специфике, сними характеристики, сравни, оформи отчетик/скриншот. Большой шанс отчету оказаться в кулуарах руководства в качестве козыря (@author Developenko, наш парень!) Никакого дара убеждения, все по специальности, по способностям. Получи за «рацуху» плюс в карму и, впоследствии, в карман. Никого не перепрыгнул, помог всем!
А быть безучастным роботом или праздным холи-воином — не стайл.
Не столько программистский мой опыт это подсказывает, сколько жизненный из других сфер деятельности.
Мы стараемся убеждать, что на проектах в продакшене менять движки можно только если есть очень-очень веские причины. И это все в команде понимают. Холивар и «я тут вчера статью прочитал, Maven лучше» — не аргумент. Недавно перевели, кстати, как раз — но по веским причинам. Переводили проект со Spring 2.5 на Spring 3.0, пришлось и на Maven заодно. Но тут вместе все просчитали, прикинули, согласовали с заказчиком (!) — и тогда уже сделали.
А кто решает веские это аргументы или нет? Как идёт обсуждение?
Хотя да, если команда проекта 4 человека с этим проблем нет.
Хотя да, если команда проекта 4 человека с этим проблем нет.
Пока что мы с Иваном главные технические и управленческие авторитеты, но это ненадолго. Ребята стремительно растут в техническом плане, мы со своей стороны стараемся поддерживать уровень осмысленности принимаемых ими решений. Мы по понятным причинам в техническом плане уже не растем и скоро они нас обгонят :-)
Вообще — в каждой технологии должен быть признанный гуру. Причем ни в коем случае не менеджер. К этому гуру народ как раз-таки ходит за советом и уже одобренное решение несет менеджеру. Конечно, менеджеры должны авторитет гуру тоже признавать. Я видела такое на своей последней наемной работе, это работает.
Вообще — в каждой технологии должен быть признанный гуру. Причем ни в коем случае не менеджер. К этому гуру народ как раз-таки ходит за советом и уже одобренное решение несет менеджеру. Конечно, менеджеры должны авторитет гуру тоже признавать. Я видела такое на своей последней наемной работе, это работает.
Я как раз тоже сторонник такого подхода. Ещё важно, чтобы гуру понимал свою ответственность, т.е. если переход на новую среду сборки провалился или занял в 3 раза больше времени, чем планировалось, он будет нести всю ответственность за это решение и никак не сможет сказать — «команда это решила».
У нас на работе сейчас получается команды работают над проектами без менеджера по сути. Есть техлид, он же архитектор, и аналитик (несколько аналитиков). Результат к сожалению получается, мягко говоря, не очень. :(
У нас на работе сейчас получается команды работают над проектами без менеджера по сути. Есть техлид, он же архитектор, и аналитик (несколько аналитиков). Результат к сожалению получается, мягко говоря, не очень. :(
Вообще — важнее всего человеческиий фактор. Как роли ни назови — без идейного лидера команда не работает.
Спасибо вам за вашу просветительскую деятельность. Ваш доклад приятно удивил на devconf'е.
Сейчас многие компании почему-то ставят акцент не на счастье программистов, а на всяческую мотивацию, «корпоративный дух» итп. В вакансиях даже задумывающихся о счастье программистов компаний самое близкое, что значится: «у нас круто» и «мы не едим по утрам младенцев»=«у нас нет злой бюрократии».
В контексте этого, у вас есть прекрасная идеализированная форма счастья, но нет пути и методов его достижения — только общее обозначение направления.
Сейчас многие компании почему-то ставят акцент не на счастье программистов, а на всяческую мотивацию, «корпоративный дух» итп. В вакансиях даже задумывающихся о счастье программистов компаний самое близкое, что значится: «у нас круто» и «мы не едим по утрам младенцев»=«у нас нет злой бюрократии».
В контексте этого, у вас есть прекрасная идеализированная форма счастья, но нет пути и методов его достижения — только общее обозначение направления.
Направление — это уже полдела. Ну и сейчас счастье присутствует, только не со всеми заказчиками еще полная гармония. Надеюсь, что скоро позволим себе выбирать, как Злые марсиане, например. Это, кстати, для нас пример, что это все может сработать.
Спасибо за пост!
Когда дочитал до «Симптомами наличия проблемы являются:» прослезился, а после «Последствия для команды (в долгосрочной перспективе):» зарыдал и захотел обнять автора, посмотреть в глаза и проникновенно сказать: «Брат! (Сестра!) Хоть ты меня понимаешь!» )
Самое интересное, что я работаю вовсе не в IT, но проблемы в плане менеджмента и организации работы прям один в один!
Молодая, маленькая компания — энергия, драйв, общая цель. Все всех знают, со всеми общаются, все — одна семья. Рост компании — больше народу и начинаются проблемы с коммуникацией, когда мессадж от клиента, полученный где-то наверху или другим подразделением, доносится до какого-то «конечного» подразделения через несколько посредников, а значит с искажениями, привнесениями и иногда с совершенно другим смыслом. При этом эти искажения появляются не только в ходе путешествий информации от клиентов, но и во внутренней коммуникации. И вот уже подразделения не видят общей цели, не понимают, куда движется компания, к чему стремится, зачем. И все сентенции топ-менеджмента о целя, задачах, планах и перспективах начинают восприниматься как послания от инопланетян, оторванных от матушки земли. И в условиях потери этого смысла начинается поиск смысла нового — ведь как-то и зачем-то подразделению нужно существовать. И когда этот смысл находится, то как правило он входит в противоречия со смыслами соседних подразделений, которые также находились в собственных поисках. И начинаются ситуации, когда бухгалтерия (юристы, продавцы, производственники, логисты, вставьте свой вариант) считает себя основной структурой компании, а всех остальных лишь вредителями, которые только и занимаются тем, что пытаются помешать им работать. Соответственно любое межподразделенческое общение по серьезным вопросам — война (открытая или скрытая, когда «общаться с вами будем только через служебки»).
Пока я ответ на вопрос «отчего так» нашел в книгах Адизеса про циклы развития компании и про стили управления. Там он очень четко объясняет, что на первых этапах нужен предпринимательский дух. Нужно придумать идею, которая продастся! Затем подключается «дух» производственный, чтобы «придуманную» предпринимателем идею воплотить в жизнь и обеспечить отгрузку продукции. А вот дальше, с ростом, как правило на сцену выходит «дух» административный, т. к. если на первых этапах компания не загнулась, то ее, разросшуюся, нужно как-то структурировать, чтобы ей можно было управлять. И вот тут-то, как мне кажется, на этом этапе, когда администрирование начинает играть важную роль, и теряется этот common cause, эта общая цель, а подразделения вместо нее получают регламенты взаимодействия, которые не дают ответ на вопрос «зачем». И этот ответ они начинают искать сами с результатами, о которых писал выше.
Адизес еще говорит о «духе» интеграции, который на самом деле является чуть ли не важнейшим и который как раз может решить эту проблему, но я пока не встречал его нигде в своей практике и у меня пока есть сомнения в том, что это осуществимо. Даже в маленькой компании из менее, чем 20 человек, где я работал, я столкнулся с тем, что руководство уже «отделено» от коллектива и нет этой интеграции. Про многотысячные корпорации я уж и не говорю
В этом плане очень интересен пример Valve с недавно облетевшей сеть книгой нового сотрудника Valve. На мой взгляд, это вот как раз пример этого самого «духа» интеграции.
Я сейчас еще хочу найти подобные же документы других компаний (Apple? Google?), чтобы посмотреть, а как там!
Вот такие вот мысли и еще раз спасибо за пост! )
Когда дочитал до «Симптомами наличия проблемы являются:» прослезился, а после «Последствия для команды (в долгосрочной перспективе):» зарыдал и захотел обнять автора, посмотреть в глаза и проникновенно сказать: «Брат! (Сестра!) Хоть ты меня понимаешь!» )
Самое интересное, что я работаю вовсе не в IT, но проблемы в плане менеджмента и организации работы прям один в один!
Молодая, маленькая компания — энергия, драйв, общая цель. Все всех знают, со всеми общаются, все — одна семья. Рост компании — больше народу и начинаются проблемы с коммуникацией, когда мессадж от клиента, полученный где-то наверху или другим подразделением, доносится до какого-то «конечного» подразделения через несколько посредников, а значит с искажениями, привнесениями и иногда с совершенно другим смыслом. При этом эти искажения появляются не только в ходе путешествий информации от клиентов, но и во внутренней коммуникации. И вот уже подразделения не видят общей цели, не понимают, куда движется компания, к чему стремится, зачем. И все сентенции топ-менеджмента о целя, задачах, планах и перспективах начинают восприниматься как послания от инопланетян, оторванных от матушки земли. И в условиях потери этого смысла начинается поиск смысла нового — ведь как-то и зачем-то подразделению нужно существовать. И когда этот смысл находится, то как правило он входит в противоречия со смыслами соседних подразделений, которые также находились в собственных поисках. И начинаются ситуации, когда бухгалтерия (юристы, продавцы, производственники, логисты, вставьте свой вариант) считает себя основной структурой компании, а всех остальных лишь вредителями, которые только и занимаются тем, что пытаются помешать им работать. Соответственно любое межподразделенческое общение по серьезным вопросам — война (открытая или скрытая, когда «общаться с вами будем только через служебки»).
Пока я ответ на вопрос «отчего так» нашел в книгах Адизеса про циклы развития компании и про стили управления. Там он очень четко объясняет, что на первых этапах нужен предпринимательский дух. Нужно придумать идею, которая продастся! Затем подключается «дух» производственный, чтобы «придуманную» предпринимателем идею воплотить в жизнь и обеспечить отгрузку продукции. А вот дальше, с ростом, как правило на сцену выходит «дух» административный, т. к. если на первых этапах компания не загнулась, то ее, разросшуюся, нужно как-то структурировать, чтобы ей можно было управлять. И вот тут-то, как мне кажется, на этом этапе, когда администрирование начинает играть важную роль, и теряется этот common cause, эта общая цель, а подразделения вместо нее получают регламенты взаимодействия, которые не дают ответ на вопрос «зачем». И этот ответ они начинают искать сами с результатами, о которых писал выше.
Адизес еще говорит о «духе» интеграции, который на самом деле является чуть ли не важнейшим и который как раз может решить эту проблему, но я пока не встречал его нигде в своей практике и у меня пока есть сомнения в том, что это осуществимо. Даже в маленькой компании из менее, чем 20 человек, где я работал, я столкнулся с тем, что руководство уже «отделено» от коллектива и нет этой интеграции. Про многотысячные корпорации я уж и не говорю
В этом плане очень интересен пример Valve с недавно облетевшей сеть книгой нового сотрудника Valve. На мой взгляд, это вот как раз пример этого самого «духа» интеграции.
Я сейчас еще хочу найти подобные же документы других компаний (Apple? Google?), чтобы посмотреть, а как там!
Вот такие вот мысли и еще раз спасибо за пост! )
Чтобы не попасть в кризис роста, надо не допускать роста :-) Есть замечательная книга От хорошего к великому, в которой описаны различные стратегии увеличения прибыли компании. Одна из них — повышение прибыли в пересчете на одного сотрудника. Мы выбрали именно ее. В этих условиях бурный рост необязателен.
Увеличение численности — соблазнительный путь, поскольку прост. Но он экстенсивный. Японцы научились выращивать редьку и свеклу, которая вглубь на метр уходит, а по площади поверхности земли, занимаемой на огороде — как обычная. Про канбан с его постоянным сокращением издержек и повышением прибыли я и не говорю.
Соответственно, чтобы увеличивать прибыль на сотрудника, надо иметь очень прокачанную и самомотивированную команду (очень рекомендую доклад Дмитрия Лобасева про«внутреннюю морковку», смеялись до слез), а так же автоматизировать все, что только можно, чтобы сократить издержки на разработку.
Тут уже звучало, что метод не промышленный — ну может и так, а на мой взгляд для аутсорсеров — самое то.
Увеличение численности — соблазнительный путь, поскольку прост. Но он экстенсивный. Японцы научились выращивать редьку и свеклу, которая вглубь на метр уходит, а по площади поверхности земли, занимаемой на огороде — как обычная. Про канбан с его постоянным сокращением издержек и повышением прибыли я и не говорю.
Соответственно, чтобы увеличивать прибыль на сотрудника, надо иметь очень прокачанную и самомотивированную команду (очень рекомендую доклад Дмитрия Лобасева про«внутреннюю морковку», смеялись до слез), а так же автоматизировать все, что только можно, чтобы сократить издержки на разработку.
Тут уже звучало, что метод не промышленный — ну может и так, а на мой взгляд для аутсорсеров — самое то.
Эх, вот только проблема в том, что компания уже выбрал экстенсивный путь и теперь с этим нужно что-то делать! )
За ссылки спасибо.
За ссылки спасибо.
Осилил текст. Благодарю! Многое срезонировало. Однако большую часть жизни я выступаю как сольный разработчик, работая напрямую с заказчиком, так сказать лицом к лицу. Всегда пристегиваюсь к профильному специалисту, работу которого предстоит автоматизировать. Как правило в первой фазе разработки добиться внятного формулирования задачи зачастую не удается. Люди банально не привыкли выражать словами то, что делают руками практически на автомате.
Из того, что удается выудить, делается прототип, который выдается на руки пользователям в максимально сжатые сроки. И тут, о чудо, у последних прорезается дар формулирования и конкретизирования, которое выливается в набор весьма четких и однозначных рекомендаций, в какую сторону трансформировать первоначальный прототип.
Работал многие годы с бухгалтерией, код писал на Clipper, окучивая нишу, на которую тогда еще не успели влезть 1С и прочие платформы. По сути все всегда сводилось к построению удобного интерфейса наполнения базы данными, и построения всевозможных срезов данных — отчеты, своды, выборки.
Очень быстро надоело клепать интерфейсы в ручном режиме, поэтому в 2003 году, потратив на это, в параллели, пару месяцев, написал небольшой фреймворк, поверх стандартного грида. В результате 90% пользовательских интерфейсов генерились уже на лету, основываясь на структуре БД и связей, которые просто прописывались в конфиге. Соответственно при каких-либо модификациях структур данных/связей нужно было обновить конфиг, и о чудо, большинство интерфейсов тут же подстраивались под новые данные. Очевидно, что все, что только возможно, выносилось в справочники, и подключалось методом подстановки через ID, что освобождало от массы проблем. Целостность справочником приходилось периодически мониторить, т.к. пользователи норовили, по лени и невнимательности, дублировать записи, с некоторыми грамматическим отличиями в написании.
Воспроизвести полный цикл на веб-платфоре мне пока не удалось, в виду разнообразного зоопарка технологий, применяемых для реализации веб-приложений. Но тот же jqGrid, да небольшой самописный фреймворк и тут спасает неплохо.
Вообще в разработке я стараюсь максимально плотно взаимодействовать с заказчиком, причем не столько с менеджментом, сколько с конкретными специалистами, т.к. «показания» представителей этих двух категорий, зачастую, весьма кардинально расходятся, как в главном, так и в деталях. И если слушать кого-то одного, то успеха достичь не удастся.
Верхи, зачастую, не вдаются в детали, даже не подозревают о них. А низы не знают целей и глобальных задач, погрязая в нюансах и инерции. Я нередко выступал в роли коммуникационного звена, интегрирую потребности и возможности обоих классов представителей заказчика, в результате и овцы были сыты, и волки целы.
Доводилось даже в некоторых задачах синхронизировать и завязывать на себя работу до 4-5 разных отделов, предварительно заручившись полной поддержкой «самого главного». Отделы выдавали данные из разных сфер и областей, которые необходимо было проинтегрировать и получить конечный срез.
Путём таких «финтов ушами» мы получали уникальную прозрачность бизнес-процессов в организации. К сожалению за последний год в той организации сменилось руководство. Новое наработками заморачиваться не стало, в результате заменив все разработки 1С и иже с ими, которые до конца настроить не смогли. В результате весь достигнутый прогресс, вся прозрачность и контроль процессов чуть менее чем полностью утрачены. Зато в мутной водице удобно ловить рыбку. Да, вы правильно догадались, контору захватили рейдеры. То, что трепетно и ответственно выстраивалось больше десятилетия, было уничтожено за несколько месяцев на корню. Увы.
Из того, что удается выудить, делается прототип, который выдается на руки пользователям в максимально сжатые сроки. И тут, о чудо, у последних прорезается дар формулирования и конкретизирования, которое выливается в набор весьма четких и однозначных рекомендаций, в какую сторону трансформировать первоначальный прототип.
Работал многие годы с бухгалтерией, код писал на Clipper, окучивая нишу, на которую тогда еще не успели влезть 1С и прочие платформы. По сути все всегда сводилось к построению удобного интерфейса наполнения базы данными, и построения всевозможных срезов данных — отчеты, своды, выборки.
Очень быстро надоело клепать интерфейсы в ручном режиме, поэтому в 2003 году, потратив на это, в параллели, пару месяцев, написал небольшой фреймворк, поверх стандартного грида. В результате 90% пользовательских интерфейсов генерились уже на лету, основываясь на структуре БД и связей, которые просто прописывались в конфиге. Соответственно при каких-либо модификациях структур данных/связей нужно было обновить конфиг, и о чудо, большинство интерфейсов тут же подстраивались под новые данные. Очевидно, что все, что только возможно, выносилось в справочники, и подключалось методом подстановки через ID, что освобождало от массы проблем. Целостность справочником приходилось периодически мониторить, т.к. пользователи норовили, по лени и невнимательности, дублировать записи, с некоторыми грамматическим отличиями в написании.
Воспроизвести полный цикл на веб-платфоре мне пока не удалось, в виду разнообразного зоопарка технологий, применяемых для реализации веб-приложений. Но тот же jqGrid, да небольшой самописный фреймворк и тут спасает неплохо.
Вообще в разработке я стараюсь максимально плотно взаимодействовать с заказчиком, причем не столько с менеджментом, сколько с конкретными специалистами, т.к. «показания» представителей этих двух категорий, зачастую, весьма кардинально расходятся, как в главном, так и в деталях. И если слушать кого-то одного, то успеха достичь не удастся.
Верхи, зачастую, не вдаются в детали, даже не подозревают о них. А низы не знают целей и глобальных задач, погрязая в нюансах и инерции. Я нередко выступал в роли коммуникационного звена, интегрирую потребности и возможности обоих классов представителей заказчика, в результате и овцы были сыты, и волки целы.
Доводилось даже в некоторых задачах синхронизировать и завязывать на себя работу до 4-5 разных отделов, предварительно заручившись полной поддержкой «самого главного». Отделы выдавали данные из разных сфер и областей, которые необходимо было проинтегрировать и получить конечный срез.
Путём таких «финтов ушами» мы получали уникальную прозрачность бизнес-процессов в организации. К сожалению за последний год в той организации сменилось руководство. Новое наработками заморачиваться не стало, в результате заменив все разработки 1С и иже с ими, которые до конца настроить не смогли. В результате весь достигнутый прогресс, вся прозрачность и контроль процессов чуть менее чем полностью утрачены. Зато в мутной водице удобно ловить рыбку. Да, вы правильно догадались, контору захватили рейдеры. То, что трепетно и ответственно выстраивалось больше десятилетия, было уничтожено за несколько месяцев на корню. Увы.
Да-да-да, сидеть рядом с пользователем и научиться делать то, что делает он, а потом понять как это автоматизировать.
Меня первый раз пробило, когда мне тетеньки-экологи показали, как они делают расчет в экселе, а потом на моей форме :-) Разница во времени — 3-5 раз. Не в мою пользу. В итоге я им сделала поведение формы в браузере с точки зрения клавиш — как в экселе, чтобы никакой мыши, переход по Enter и т.д. В итоге они смогли использовать свою моторную память и были довольны.
Меня первый раз пробило, когда мне тетеньки-экологи показали, как они делают расчет в экселе, а потом на моей форме :-) Разница во времени — 3-5 раз. Не в мою пользу. В итоге я им сделала поведение формы в браузере с точки зрения клавиш — как в экселе, чтобы никакой мыши, переход по Enter и т.д. В итоге они смогли использовать свою моторную память и были довольны.
В моём случае они заполняли вручную огромные тетради, которые называются «полотенца». Причем проверяли и перепроверяли расчеты по много раз, т.к. неизбежны ошибки. Все это происходило при помощи калькулятора, который нередко «затуплял». В общем 2 недели в месяце им было ну очень весело.
По первости они дублировали процесс, т.е. заполняли все те же тетради, и заносили данные в программу. Второе занимало гораздо меньше времени, т.к. не нужно было ничего пересчитывать, а если где в данных и закрадывались ошибки, находить их было на порядки проще и быстрее, менее трудоёмко.
Сначала они проверяли программу по тетради, через пару месяцев уже проверяли тетрадь по программе. Через 4 или 5 месяцев тетради отложили в сторону и заменили распечатками из программы. Программа отработала как часики с 2003-2004 по 2012, пока ей на смену не пришла 1С.
Каждый раз когда меня спрашивали, а можно ли получить вот такой срез/выборку/отчет/свод? Я говорил — данные в базе есть? Не вопрос. Если работа была одноразовая, то я делал вручную. Если многократная, то я писал дополнительный модуль к программе, и в дальнейшем уже отчет они получали автоматически.
Это пример только одной программы. Их было много. :)
Последние пару-тройку лет от Клиппера я уже отказался, в силу его весьма скудного инструментария, по отношению к тому же PHP/MySQL. Некоторые программы до сих пор работают, а я уже год как оттуда уволился.
По первости они дублировали процесс, т.е. заполняли все те же тетради, и заносили данные в программу. Второе занимало гораздо меньше времени, т.к. не нужно было ничего пересчитывать, а если где в данных и закрадывались ошибки, находить их было на порядки проще и быстрее, менее трудоёмко.
Сначала они проверяли программу по тетради, через пару месяцев уже проверяли тетрадь по программе. Через 4 или 5 месяцев тетради отложили в сторону и заменили распечатками из программы. Программа отработала как часики с 2003-2004 по 2012, пока ей на смену не пришла 1С.
Каждый раз когда меня спрашивали, а можно ли получить вот такой срез/выборку/отчет/свод? Я говорил — данные в базе есть? Не вопрос. Если работа была одноразовая, то я делал вручную. Если многократная, то я писал дополнительный модуль к программе, и в дальнейшем уже отчет они получали автоматически.
Это пример только одной программы. Их было много. :)
Последние пару-тройку лет от Клиппера я уже отказался, в силу его весьма скудного инструментария, по отношению к тому же PHP/MySQL. Некоторые программы до сих пор работают, а я уже год как оттуда уволился.
Мой модуль для экологов тоже до сих пор работает, никто им не занимается. Я уходила в декрет в 2006-м, с тех пор я его не правила. У них очень медленно меняются процессы, поэтому изменений софта могут не требовать годами :-)
А еще в 2006-м их начальница мне сказала: хватит все автоматизировать, а то вместо отдела оставят одного человека, уймись!
А еще в 2006-м их начальница мне сказала: хватит все автоматизировать, а то вместо отдела оставят одного человека, уймись!
Скажите, а как вы боритесь с текучкой кадров?
Если в один месяц у вас по разным причинам отвалится 4 человека? 1 в отпуске, 1 болеет, 2 уволились?
Для большой компании 4 человека будут проблемой, но не смертельной, а для команды в 5 человек это может привести к закрытию бизнеса.
Если в один месяц у вас по разным причинам отвалится 4 человека? 1 в отпуске, 1 болеет, 2 уволились?
Для большой компании 4 человека будут проблемой, но не смертельной, а для команды в 5 человек это может привести к закрытию бизнеса.
Ну вообще. отпуска неожиданными бывают редко. Планируем так, чтобы вся проектная команда не уходила в отпуск одновременно. С этой целью, например, супругов стараюсь по разным командам разводить, но не всегда получается :-)
Да, в маленькой команде риски выше. Но в маленькой команде проще увидеть недовольство и вовремя поговорить с человеком, выяснить что не так и разрешить проблему, которая мешает ему остаться в команде. Опять же человеческое отношение к сотрудникам позволяет не получать неожиданных заявлений на стол. Все, кто уходил, уходили так, чтобы никого не подставить. Как ты к людям, так и они к тебе.
В маленькой команде семейного типа люди редко берут больничный из-за легкого насморка (как часто делают в больших бюрократически раздутых конторах). Они остаются дома, но работают оттуда, чтобы никого не подводить, если позволяет самочувствие.
Да, в маленькой команде риски выше. Но в маленькой команде проще увидеть недовольство и вовремя поговорить с человеком, выяснить что не так и разрешить проблему, которая мешает ему остаться в команде. Опять же человеческое отношение к сотрудникам позволяет не получать неожиданных заявлений на стол. Все, кто уходил, уходили так, чтобы никого не подставить. Как ты к людям, так и они к тебе.
В маленькой команде семейного типа люди редко берут больничный из-за легкого насморка (как часто делают в больших бюрократически раздутых конторах). Они остаются дома, но работают оттуда, чтобы никого не подводить, если позволяет самочувствие.
Я понимаю, что вы говорите, у меня сейчас в команде такая же ситуация, НО вопрос был в другом. Как вы боритесь с текучкой кадров с точки зрения управления командой? Как оцениваете эти риски?
p.s. Я видел пример, когда из «команды» в 7 человек, за год ушли 4, хотя все пьянки, гулянки и т.д. были проводили вместе. Уходили люди по разным причинам, но с фактами не поспоришь. Что сейчас делает ПМ, я не знаю. Но, я бы, наверное, ушёл бы тоже оттуда на его месте.
p.s. Я видел пример, когда из «команды» в 7 человек, за год ушли 4, хотя все пьянки, гулянки и т.д. были проводили вместе. Уходили люди по разным причинам, но с фактами не поспоришь. Что сейчас делает ПМ, я не знаю. Но, я бы, наверное, ушёл бы тоже оттуда на его месте.
Пока что за 2 года с проблемой не столкнулись. Все, кто ушел, либо не подходили по духу, либо сильно заранее предупреждали и уходили, никого не подставляя. Последние, кстати, периодически заходят в гости, кто в городе, и остаются в общих чатах команды (кроме проектных). Дают советы по вопросам своей компетенции всем сотрудникам, даже тем, с кем не успели познакомиться лично.
Конечно, я видела и другие случаи, но чаще всего, там были все-таки внутренние проблемы того или иного сорта.
Риск есть для меня в двух случаях: мы накосячим или кто-то резко начнет бомбардировать ребят с предложением зарплаты в 2-3 раза выше. Со вторым мы вряд ли сможем что-либо сделать, кроме повышения зарплат. Это по сути форс-мажор, как нынче со «Сбербанк-технологиями» в Java-мире.
Скажу совсем крамольную мысль — мы не расстроимся, если все наши ребята разойдутся по крутым конторам и от нашей ничего не останется. Мы будем считать свою миссию выполненной в каком-то смысле, да и сами не пропадем :-)
Конечно, я видела и другие случаи, но чаще всего, там были все-таки внутренние проблемы того или иного сорта.
Риск есть для меня в двух случаях: мы накосячим или кто-то резко начнет бомбардировать ребят с предложением зарплаты в 2-3 раза выше. Со вторым мы вряд ли сможем что-либо сделать, кроме повышения зарплат. Это по сути форс-мажор, как нынче со «Сбербанк-технологиями» в Java-мире.
Скажу совсем крамольную мысль — мы не расстроимся, если все наши ребята разойдутся по крутым конторам и от нашей ничего не останется. Мы будем считать свою миссию выполненной в каком-то смысле, да и сами не пропадем :-)
Я правильно понял ответ: мы никак не работаем с этими рисками?
И второй момент, если ребята разойдутся по крутым конторам, и проект свалится по всем срокам — это нормально?
И второй момент, если ребята разойдутся по крутым конторам, и проект свалится по всем срокам — это нормально?
А как вы оцениваете вероятность — все остальные риски недовольной команды vs гипотетическая возможность появления в Омске конторы с зарплатами x2?
Ребята не разойдутся, бросив проект. Не те ребята :-)
Да, я никак не работаю с этими рисками в том смысле, который имеете в виду Вы. Я не рисую диаграммы и не оцениваю вероятности. И не потому, что не знаю о том, что это делают другие компании. Я читала книгу Ди Марко и Листера Вальсируя с медведями, на AgileCamp с удовольствием принимала участие в тренинге от хабраюзера blv, и т.д.
Я осознанно приняла решение, что в наших условиях все это излишне. Все, что я могу сделать, это не покупать лексусы за счет недоплаченных зарплат и быть своей команде другом, а не цербером. Пока что это работает. К сожалению, метод слишком индивидуален и в качестве общего рецепта не годится (хотя человееское отношение к команде вряд ли будет вредным советом :-)).
Я осознанно приняла решение, что в наших условиях все это излишне. Все, что я могу сделать, это не покупать лексусы за счет недоплаченных зарплат и быть своей команде другом, а не цербером. Пока что это работает. К сожалению, метод слишком индивидуален и в качестве общего рецепта не годится (хотя человееское отношение к команде вряд ли будет вредным советом :-)).
Спасибо! Это лучшее за последнее время на хабре =)
Действительно, некоторые ситуации один в один похожи на случившиеся со мной или со знакомыми. Многое из написанного знакомо. По поводу некоторых капитанских вещей, я не устаю повторять себе «Повторение — мать ученья». Всегда во всем давно известном можно найти что-то новое.
Действительно, некоторые ситуации один в один похожи на случившиеся со мной или со знакомыми. Многое из написанного знакомо. По поводу некоторых капитанских вещей, я не устаю повторять себе «Повторение — мать ученья». Всегда во всем давно известном можно найти что-то новое.
Текст интересный и большой, но сложно читать. Было бы круто видеть логические разделения, подзаголовки.
Вот, кстати, да — текст неструктурированный. Осиливается тяжело.
Поторопилась, да. На конференции он был разбит по слайдам, там этого не чувствовалось
А на слайдшере есть? Я бы еще раз ознакомился, но уже в слайдах!
Надеюсь. меня не забанят за кросс-пост :-) Презентация с DevConf
Вторая половина статьи читается как исторический роман. Что-то типа «как мы зафакапили всё, что можно» :-)
Я только не понял, к настоящему моменту что уже есть, кроме принципов счастья и пожелания команды из высокоуровневых коллег?
Я только не понял, к настоящему моменту что уже есть, кроме принципов счастья и пожелания команды из высокоуровневых коллег?
Sign up to leave a comment.
Производство счастья промышленными методами