Comments 31
Обнаружив, что разработчики часто довольно туманно представляют себе, как устроены «глобальные» бизнес процессы в компании, я решил попробовать объяснить разработчикам, с какими проблемами сталкиваются те, кто пытается организовать их труд и направить его в «мирное русло».
C одной стороны согласен в том что психовать и разбегаться не конструктивно, с другой — в этом и смысл менеджмента чтоб организовывать работу разработчиков чтоб им не пришлось сталкиваться с этими проблемами. И чтоб эти проблемы разрешались до того как человек успеет написать разбор «цепочки ситуаций» — таких цепочек вообще не должно быть (так же как не должно быть багов в коде, ага).
Это как если разработчик срывающий сроки пришлет проджект манагеру 15 тыщ строк кода со словами что вот этот момент не совсем понятен давайте подумаем вместе.
C одной стороны согласен в том что психовать и разбегаться не конструктивно, с другой — в этом и смысл менеджмента чтоб организовывать работу разработчиков чтоб им не пришлось сталкиваться с этими проблемами. И чтоб эти проблемы разрешались до того как человек успеет написать разбор «цепочки ситуаций» — таких цепочек вообще не должно быть (так же как не должно быть багов в коде, ага).
Это как если разработчик срывающий сроки пришлет проджект манагеру 15 тыщ строк кода со словами что вот этот момент не совсем понятен давайте подумаем вместе.
Понравилось признание того факта, что менеджера тоже косячат. Согласен с этим. И, кстати, косячат не изредка, а основательно так: увольняют не того, принимают не того человека на работу. А расхлебывать потом всей команде. И еще требуют предсказывать будущее: «сколько времени у вас займет...».
Не согласен с тем фактом, что клиент должен нам говорить где ошибка и что поправить. Клиенты действительно молча ругаются и уходят. Мы сами должны организовать эффективную обратную связь и выпрашивать у них нужную нам информацию.
Та же ситуация и с менеджерами: менеджер должен признавать свои ошибки. Можно ведь раз в неделю собрать людей и спросить «ребята, где я сильно косячу, где облажался?» Можно объяснить разработчикам свою ситуацию, и всем вместе подумать над ее решением.
Или ситуация «программист обиделся и ушел». Программист не должен по каждому поводу ходить и жаловаться: мне не нравится то, мне не нравится это. Его основная задача — программировать. А вот задача менеджера — обеспечивать максимальную эффективность своей команды. И лучший способ достичь этого — это постоянно интересоваться как идут дела и всех и каждого.
Программисты любят менеджеров. Хороших менеджеров. Достаточно раз поработать под руководством хорошего менеджера, чтобы видеть всех говноменеджеров насквозь. Посредственный менеджмент — бич современной разработки.
Не согласен с тем фактом, что клиент должен нам говорить где ошибка и что поправить. Клиенты действительно молча ругаются и уходят. Мы сами должны организовать эффективную обратную связь и выпрашивать у них нужную нам информацию.
Та же ситуация и с менеджерами: менеджер должен признавать свои ошибки. Можно ведь раз в неделю собрать людей и спросить «ребята, где я сильно косячу, где облажался?» Можно объяснить разработчикам свою ситуацию, и всем вместе подумать над ее решением.
Или ситуация «программист обиделся и ушел». Программист не должен по каждому поводу ходить и жаловаться: мне не нравится то, мне не нравится это. Его основная задача — программировать. А вот задача менеджера — обеспечивать максимальную эффективность своей команды. И лучший способ достичь этого — это постоянно интересоваться как идут дела и всех и каждого.
Программисты любят менеджеров. Хороших менеджеров. Достаточно раз поработать под руководством хорошего менеджера, чтобы видеть всех говноменеджеров насквозь. Посредственный менеджмент — бич современной разработки.
Менеджмент не делает никакой полезной работы, и у него не должно быть ошибок. Цель менеджмента — чтобы всё внезапно не развалилось, и если менеджмент не делает хуже, это уже хорошая работа, даже если и не становится лучше.
Согласен с пунктом про обязательства и скорый отход из компании — попахивает очень плохо.
Кто-то может сказать, что менеджмент нужен для того, чтобы дать разработчику время и возможность разрабатывать, чтобы оградить его от орг. вопросов. Но если подумать и убрать всех управленцев — оставить только сферическую пару программиста и заказчика в вакууме, то они точно так же создадут нормальный продукт в силу своих возможностей, желаний и т.п.
Менеджмент нужен для главы компании и остальных управленцев выше разработчика в иерархии компании.
Согласен с пунктом про обязательства и скорый отход из компании — попахивает очень плохо.
Кто-то может сказать, что менеджмент нужен для того, чтобы дать разработчику время и возможность разрабатывать, чтобы оградить его от орг. вопросов. Но если подумать и убрать всех управленцев — оставить только сферическую пару программиста и заказчика в вакууме, то они точно так же создадут нормальный продукт в силу своих возможностей, желаний и т.п.
Менеджмент нужен для главы компании и остальных управленцев выше разработчика в иерархии компании.
Вы совершенно неверно представляете цели менеджмента.
Менеджмент делает ошибки, они могут быть куда дороже и хуже багов — это правда, главное что-бы менеджмент как и любая другая роль, учились на этих ошибках…
Менеджмент делает ошибки, они могут быть куда дороже и хуже багов — это правда, главное что-бы менеджмент как и любая другая роль, учились на этих ошибках…
С удовольствием узнал бы об этой Цели.
Цель — организовать чтобы работало.
Чтобы вы не пинали балду.
Чтобы было можно запускать ракеты в космос, а не мастерить каменные топоры.
Во всех задачах, где один человек справится своими силами не может, требуется менеджер
Чтобы вы не пинали балду.
Чтобы было можно запускать ракеты в космос, а не мастерить каменные топоры.
Во всех задачах, где один человек справится своими силами не может, требуется менеджер
Про организовать(рабочее место?) понятно, на то программист и наёмный рабочий.
Если работник пинает балду — его выгоняют. В этом нет никакого секрета. Есть смысл ради этого платить ещё одному человеку зарплату?
А как разработчик мастерит каменные топоры вместо запуска ракеты в космос? Менеджер сидит и указывает ему что писать и как? Да ладно?
Ну а насчёт всех задач… Существуют старшие разработчики, архитекторы, тимлиды, они ведь не менеджеры? Но именно они координируют работу, и работают, создают полезный выхлоп, чего я бы не сказал о менеджере. Да вот вы вспомните университет к примеру — там несколько студентов без менеджеров делают то что им нужно — курсовой, к примеру.
Нет, я согласен, менеджеры нужны, но ИМХО, их роль слишком переоценена. Америка стайл.
Если работник пинает балду — его выгоняют. В этом нет никакого секрета. Есть смысл ради этого платить ещё одному человеку зарплату?
А как разработчик мастерит каменные топоры вместо запуска ракеты в космос? Менеджер сидит и указывает ему что писать и как? Да ладно?
Ну а насчёт всех задач… Существуют старшие разработчики, архитекторы, тимлиды, они ведь не менеджеры? Но именно они координируют работу, и работают, создают полезный выхлоп, чего я бы не сказал о менеджере. Да вот вы вспомните университет к примеру — там несколько студентов без менеджеров делают то что им нужно — курсовой, к примеру.
Нет, я согласен, менеджеры нужны, но ИМХО, их роль слишком переоценена. Америка стайл.
Кто выгоняет? Если управленцев нет?
Менеджер помогает организовать взаимодействие между людьми.
И чем больше коллектив тем больше энергии тратится на внутренние связи.
Так вот эти самые менеджеры-управленцы и призваны снижать затраты на коммуникации внутри коллектива.
Насколько эффективно они делают это другой вопрос.
А пример с топорами и ракетами был призван показать разницу между 1-2 людьми при работе с топорами и сотнями тысяч людьми при разработке ракет.
И для справки — team lead это во многом уже больше менеджер нежели разработчик.
Менеджер помогает организовать взаимодействие между людьми.
И чем больше коллектив тем больше энергии тратится на внутренние связи.
Так вот эти самые менеджеры-управленцы и призваны снижать затраты на коммуникации внутри коллектива.
Насколько эффективно они делают это другой вопрос.
А пример с топорами и ракетами был призван показать разницу между 1-2 людьми при работе с топорами и сотнями тысяч людьми при разработке ракет.
И для справки — team lead это во многом уже больше менеджер нежели разработчик.
Эта проблема слишком распространена, но почему-то многие не могут понять причин, и борются со следствиями. Как правило подобные проблемы возникают из-за разного положения сотрудников в компании, как по обязанностям, так и по должностям. Сама модель «начальник-исполнитель», в этом случае начинает деструктивно влиять на весь процесс, и с ростом компании, весь механизм идет в разнос. Я не говорю, что все проблемы именно по этой причины, но отсутствие обратной связи как как правило из-за этого и возникает.
Вот на примере этой статьи я снова вижу одни и те же ошибки, люди делят единый организм (компанию), на псевдоорганизмы (менеджмент и исполнители), и пытаются строить правила игры. Конечно, правила игры нужны, но вам в начальника поиграть, или делом заниматься? Если делом, то не создавайте искусственных преград в общении, и будем вам счастье. Не отдаляйтесь от сотрудников, но и не становитесь навязчивыми. Эти правила просты, относятся не только к программистам, а вообще к любой профессии.
На эту тему недавно появилась замечательная, на мой взгляд, статья.
Вот на примере этой статьи я снова вижу одни и те же ошибки, люди делят единый организм (компанию), на псевдоорганизмы (менеджмент и исполнители), и пытаются строить правила игры. Конечно, правила игры нужны, но вам в начальника поиграть, или делом заниматься? Если делом, то не создавайте искусственных преград в общении, и будем вам счастье. Не отдаляйтесь от сотрудников, но и не становитесь навязчивыми. Эти правила просты, относятся не только к программистам, а вообще к любой профессии.
На эту тему недавно появилась замечательная, на мой взгляд, статья.
Более того — подозреваю, что в России Большее количество именно таких(больших) начальников, описанных в статье —
будешь делиться с ними обратной связью, и только быстрее перестанешь работать в компании,
но в том случае не ты уйдешь, а тебя уйдут. :)
будешь делиться с ними обратной связью, и только быстрее перестанешь работать в компании,
но в том случае не ты уйдешь, а тебя уйдут. :)
Это и реальность и миф. Реальность да, так бывает, но эта реальность создает миф и подсознательный страх, что тебя могут уволить аргументировав это тем, что ты «зря что-ли зарплату получаешь!? вон Вася работает, и у него никаких проблем в коде нет, а ты мне только плохие новости и можешь приносить!».
А мне кажется, что обратная связь всегда нужна, но не все могут хорошо её донести. Как наглядный пример проблемы — сегодня на хабре есть свежая статья про собеседования и говорить причины отказа или нет.
И ещё мне кажется, что хорошего профессионала, будь он хоть дворник, всегда где-то ждут. Есть повод для самосовершенствования :)
И иногда нужно отдавать себе отчёт в том, что все в какой-то мере боятся неопределённости, особенно с возрастом, чем поиск новой работы и является.
Так что говорить правду нужно. А проблему превосходности компании и плохого человека в менеджменте решать по мере желания, потому что над всеми есть начальник, а над самым верхним — жажда денег, славы и прочие :)
И ещё мне кажется, что хорошего профессионала, будь он хоть дворник, всегда где-то ждут. Есть повод для самосовершенствования :)
И иногда нужно отдавать себе отчёт в том, что все в какой-то мере боятся неопределённости, особенно с возрастом, чем поиск новой работы и является.
Так что говорить правду нужно. А проблему превосходности компании и плохого человека в менеджменте решать по мере желания, потому что над всеми есть начальник, а над самым верхним — жажда денег, славы и прочие :)
> программистов, которые отдали Клиенту вообще никак не оттестированный код, нельзя оштрафовать даже на пару сотен
Совершенно верно сказано. Организация рабочего процесса, позволяющая никак не оттестированному коду попадать в руки заказчика, — это вина только менеджера.
Совершенно верно сказано. Организация рабочего процесса, позволяющая никак не оттестированному коду попадать в руки заказчика, — это вина только менеджера.
Вероятно, автор имеет в виду ситуацию, когда разработчик даже ни разу не запустил написанный код, и в итоге оказалось, что продукт не проходит даже проверку «на дым» — т.е. критический баг лежит на поверхности. В этом, конечно же, вина разработчика присутствует.
А вот то, что такой продукт попал к клиенту — это конечно же вина менеджера, т.к. явно нарушен процесс.
А вот то, что такой продукт попал к клиенту — это конечно же вина менеджера, т.к. явно нарушен процесс.
гм… а тестеров нанять? а самим посмотреть? я вообще себе ситуацию такую не могу представить, чтобы никто, кроме разработчика, не посмотрел на работу программы. однозначная ошибка в организации.
Обратная связь — дело, конечно, хорошее и нужное. Но прежде всего у рядовых сотрудников должна быть четкая уверенность, что их критика не приведет к мести со стороны обиженного начальства. И, конечно, одного честного слова начальства тут будет недостаточно. Одно из решений — анонимная обратная связь. Но и этого недостаточно, ибо все понимают, что очень часто критика легко вычислить просто по стилю письма…
Теперь по поводу обид на то, что «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит». Если программистам дается новое задание, то предполагается что от них будут поступать какие-то сведения о продвижении дела. Ну, типа «мы сможем взяться за ваше задание через три недели — у нас уже есть очередь». Через три недели: «Мы взялись за задание, предполагаем сделать через месяц». Еще через две недели: «Работа идет по графику, но возможна задержка на три дня», ну и так далее. Нужна прозрачность. И это же хочется видеть у руководства. Программисты пожаловались, скажем, на то, что новые правила работы с документами отнимают слишком много времени, и в ответ, помимо «Спасибо, мы учтем ваше мнение» хочется слышать что-то конкретное — когда и как это будет рассмотрено и т.п.
Ну, и последнее. Я работю в Штатах, и мне совершенно дико слышать про штрафы сотрудников. Здесь такого нет, и я не понимаю, зачем они нужны. Если в результате клиент получил плохой продукт, то проблема лежит в процессе, который допустил это (а где QA? ) и в руководстве, которое такой процесс создало. Вина общая, штрафовать никого не надо.
Теперь по поводу обид на то, что «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит». Если программистам дается новое задание, то предполагается что от них будут поступать какие-то сведения о продвижении дела. Ну, типа «мы сможем взяться за ваше задание через три недели — у нас уже есть очередь». Через три недели: «Мы взялись за задание, предполагаем сделать через месяц». Еще через две недели: «Работа идет по графику, но возможна задержка на три дня», ну и так далее. Нужна прозрачность. И это же хочется видеть у руководства. Программисты пожаловались, скажем, на то, что новые правила работы с документами отнимают слишком много времени, и в ответ, помимо «Спасибо, мы учтем ваше мнение» хочется слышать что-то конкретное — когда и как это будет рассмотрено и т.п.
Ну, и последнее. Я работю в Штатах, и мне совершенно дико слышать про штрафы сотрудников. Здесь такого нет, и я не понимаю, зачем они нужны. Если в результате клиент получил плохой продукт, то проблема лежит в процессе, который допустил это (а где QA? ) и в руководстве, которое такой процесс создало. Вина общая, штрафовать никого не надо.
чтобы в программе было меньше ошибок, хорошие программисты пишут тесты. и получают обратную связь самостоятельно.
для менеджера сидеть и ждать обратной связи — смертный грех. это работа руководителя знать все, что происходит в коллективе. у кого ребенок родился, у кого родственник заболел, кого задолбало несколько лет подряд делать одинаковые проекты — руку на пульсе держать надо, а не жаловаться на молчаливых программистов. а то вы не в курсе, что большинство из них/нас интроверты — сейчас, побежали сами обо всем говорить. менеджер психологом хорошим должен быть, на худой конец хоть немножко думать головой.
ну, а то, что к клиенту попала непротестированная программа — это ошибка менеджмента и технического руководства. не организовали процесс тестирования, пожалели денег на тестировщиков, не выделели программисту дополнительные часы на unit тесты и интеграционное тестирование.
не надо жаловаться — работать нормально нужно.
для менеджера сидеть и ждать обратной связи — смертный грех. это работа руководителя знать все, что происходит в коллективе. у кого ребенок родился, у кого родственник заболел, кого задолбало несколько лет подряд делать одинаковые проекты — руку на пульсе держать надо, а не жаловаться на молчаливых программистов. а то вы не в курсе, что большинство из них/нас интроверты — сейчас, побежали сами обо всем говорить. менеджер психологом хорошим должен быть, на худой конец хоть немножко думать головой.
ну, а то, что к клиенту попала непротестированная программа — это ошибка менеджмента и технического руководства. не организовали процесс тестирования, пожалели денег на тестировщиков, не выделели программисту дополнительные часы на unit тесты и интеграционное тестирование.
не надо жаловаться — работать нормально нужно.
Всё дело в отношении.
Если даже менеджер косячит, но при этом старается обсуждать важные решения с командой, если нет бычек на ровном месте, то я легко вхожу в его положение.
Но когда приходит новый менеджер и начинает гавкать по делу и без дела, то мне проще сменить место работы, т.к. мне душевное спокойствие важнее.
Инициатива «работы с коллективом», думаю, должна исходить от менеджера. Просто потому что обычно менеджер является начальником.
Если даже менеджер косячит, но при этом старается обсуждать важные решения с командой, если нет бычек на ровном месте, то я легко вхожу в его положение.
Но когда приходит новый менеджер и начинает гавкать по делу и без дела, то мне проще сменить место работы, т.к. мне душевное спокойствие важнее.
Инициатива «работы с коллективом», думаю, должна исходить от менеджера. Просто потому что обычно менеджер является начальником.
Открою вам одну страшную тайну. Хороших разработчиков очень мало, и мы/они очень капризные. И по большому счету все что нужно менеджерам это не мешать разработчикам, нужно просто научиться направлять энергию разработчиков в нужное для компании русло. Ну а любые попытки давления, штрафы и вообще любые действия которые «демотивируют разработчиков» приведут к вполне закономерной текучке кадров.
Я вообще считаю что штрафы это худшая мотивация не только для разработчиков но и для вообще всех работников.
Но если тетя Глаша из бухгалтерии боясь потерять работу терпит штрафы, а разработчики при этом «в наглую» и открыто говорят что не потерпят никаких штрафов, ибо новую работу не хуже они точно найдут — то тут не надо с пафосом рассуждать про «общую ответственность, общую цель, гимн компании хором распеваемый сотрудниками и проч бред» а надо менять свое отношения к людям.
Когда после внедрения какой либо фишки доход компании резко возрастет, люди реализовавшие эту фишку не получат прибавку к зп соразмерную с увеличившимся доходом (что логично и вполне ожидаемо), они получат просто зп, ибо договор тоже они подписывали на определенный оклад, так что и потери компании не должны никак сказываться на зп работников.
Я вообще считаю что штрафы это худшая мотивация не только для разработчиков но и для вообще всех работников.
Но если тетя Глаша из бухгалтерии боясь потерять работу терпит штрафы, а разработчики при этом «в наглую» и открыто говорят что не потерпят никаких штрафов, ибо новую работу не хуже они точно найдут — то тут не надо с пафосом рассуждать про «общую ответственность, общую цель, гимн компании хором распеваемый сотрудниками и проч бред» а надо менять свое отношения к людям.
Когда после внедрения какой либо фишки доход компании резко возрастет, люди реализовавшие эту фишку не получат прибавку к зп соразмерную с увеличившимся доходом (что логично и вполне ожидаемо), они получат просто зп, ибо договор тоже они подписывали на определенный оклад, так что и потери компании не должны никак сказываться на зп работников.
Так реализация фишки является обычной работой разработчика. С чего бы это как то выделять. Понятнее премировать того кто придумал фишку увеличившую доход, в том числе даже если это разработчик.
> Понятнее премировать того кто придумал фишку
Прецеденты на вашей памяти были?
Вообще я понял одно, платить надо столько чтобы человек вообще не задумывался о премиях, леваках и проч.
И тот же Брукс вместе с Де Марко подтверждают что премии не всегда мотивируют положительно, особенно всякие ежеквартальные/ежечего то там — к ним человек быстро привыкает и относится точно так же как и к обычной зп
Прецеденты на вашей памяти были?
Вообще я понял одно, платить надо столько чтобы человек вообще не задумывался о премиях, леваках и проч.
И тот же Брукс вместе с Де Марко подтверждают что премии не всегда мотивируют положительно, особенно всякие ежеквартальные/ежечего то там — к ним человек быстро привыкает и относится точно так же как и к обычной зп
были, хотя у меня не очень большое количество работодателей для статистики.
а по поводу премий полностью соглашусь. идеальный вариант 13я зарплата как мне кажется :)
Интересно, а премия в виде опциона мотивировала бы лучше чем «обычная» премия*?
Зависит от многих факторов. Какой опцион, на каких условиях его дают (например увидев пунктик про аннулирование после увольнения я бы от такого опциона отказался — ибо сие больше смахивает на попытки привязать сотрудника к текущему месту)
Еще в России часто практикуют выдачу кредита на «более лучших» условиях чем в банке для ключевых сотрудников, это уже совсем хомут на шее, такой сотрудник точно никуда не свалит по крайней мере на срок погашения кредита
Еще в России часто практикуют выдачу кредита на «более лучших» условиях чем в банке для ключевых сотрудников, это уже совсем хомут на шее, такой сотрудник точно никуда не свалит по крайней мере на срок погашения кредита
Уважаемые коллеги!
Ща подолью масла в огонь. Статью я писал долго, несколько дней. А комментарии горячие. Где-то могут оказаться неполиткорректными.
Я совсем не утверждаю, что за менеджемент в компании отвечают программисты. Я просто пытался объяснить, что если Вы видите недостатки, то, естетственно, о них сказать (а не ждать, что они исчезнут сами собой по мановению волшебной палочки) и этим помочь их исправить. Лучший вариант для ускоренного развития – это сотрудничество всех, кому не всё равно. Программисты совершают ошибки, но могут исправить их, если им на них указать. И менеджеры тоже совершают ошибки. И тоже могут их исправить, если им показать, где они не правы.
Я, естественно, имею в виду правильных менеджеров и правильных программистов. Программиста, который вместо «Спасибо» за обнаруженный косяк и его исправления постарается замести мусор под ковёр и соскочить, нужно гнать поганой метлой из профессии.
Ровно тоже касается и менеджеров. Не нужно бояться увольнения за критику. В компании, где могут за это уволить, работать просто не стоит. У такой компании нет серьёзного будущего, поскольку в ней заблокирован базовый механизм самосовершенствования. Не нужно бояться увольнения из такой компании. Напротив, нужно самому энергично искать другую работу.
Что касается невыстроенных процессов, из-за которых Клиенту попал неоттестированный код, то любые процессы могут дать сбой, если участники нарушают технологию. Пусть выстроен совершенно правильный конвеер, но кто-то в цепочке недокручивает гайки. На выходе — брак. Любая технология состоит не только из набора процедур и правил, но и из решимости их выполнять. Нарушения способны похерить общий результат.
В описанном случае при обновлении у Клиента вылезла критическая проблема, которая не ловилась на тестовых данных. Её вынуждены были править на горячую. Стандартная технология осознанно нарушалась. Это могло бы пройти вполне нормально. У Клиента стоял бизнес, и он не готов был ждать официального выхода следующего релиза. Но, ЗАТО, готов был рискнуть. Надеясь, в том числе, на нашу сознательность.
В подобных случаях очень важно чувство личной ответственности, потому что оно, в значительной степени, компенсирует последствия нарушений правил выпуска. В критических случаях ваши коллеги имеют право рассчитывать на то, что вы делаете свою часть работы добросовестно. Я не вижу ничего военного в том, что вы разделите ответственность с другими за свою недоработку. В нашем случае наши сотрудники восприняли всё правильно – и я им за это благодарен. Они честно приняли отвественность на себя. И начали процесс планомерных улучшений, результатами которого я сегодня искренне впечатлён.
Ещё раз – штраф (огромная редкость и ЧП в нашей компании) был следствием откровенного нарушения правил. Это стоило многим людям бессонных ночей и больших переработок. Вы всерьёз полагаете, что наказаний за нарушения, приведшие к тяжким последствиям, быть не должно? Что можно отделаться словами о том, что виноват процесс, над которым нужно поработать всем?
Вот, например, водитель на дороге нарушил скоростной режим и сбил пешехода. Никаких инновационных методов регулирования скоростного режима не было применено, только знак «40» и «Осторожно — дети». Вы скажете, что нужно об общих процессах подумать, которые к этому привели, а виновника отпустить на восвояси? Нормально?
Я думаю, что надо и о процессах думать и об индивидуальной ответственности не забывать. Без такой индивидуальной ответственности вы далеко не уедете. Процессы лишь помогают людям более эффективно свою индивидуальную ответственность реализовать. Сама идея о том, что от индивидуальной ответственности нужно уходить, кажется мне ущербной.
Как бы ни было в мире мало хороших разработчиков. Иначе их станет ещё меньше!
То, что хороших разработчиков мало, не оправдывает раздолбайства и безответственности. Конечно, вас мало и вы вольны вести себя так, как вам заблагорассудится. А я волен давать этому свою этическую оценку. Я, к счастью, знаю очень хороших разработчиков, которым не придёт в голову утверждать, что человек, который по их милости провёл вечер с их глючной прогой вместо того, чтобы повозиться со своей маленькой дочуркой, ДОЛЖЕН ЭТО СМИРЕННО ТЕРПЕТЬ, ПОТОМУ ЧТО ХОРОШИХ РАЗРАБОТЧИКОВ МАЛО.
Я рад, что работаю с ними. Они прекрасно понимают, что от качества продуктов зависит личное время многих тысяч людей, их семейные отношения, их карьеры, их зарплата.
Что касается примера работы в Штатах, то американские компании существуют в условиях, заметно более мягких, чем мы. Просто переносить систему отношений на наши условия не получится, поскольку наши условия много жёстче. Их Клиенты обычно платят им, самое малое, 250$ за час работы специалиста. Нам же пока платят впятеро меньше.
Зарплаты же у нас пониже. Но не в разы. А всего лишь на десятки процентов. Зато затраты на оборудование повыше, чем в Штатах. А накладные, вследствие необходимости взаимодействовать с отечественной бюрократией, больше. Доходы много меньше, расходы заметно больше. Вряд ли мы можем в лоб применять американские бизнес модели и модели внутренних взаимоотношений. Мы ухитряемся жить и расти в предельно трудных условиях (как лишайник на севере), постоянно заботясь об увеличении собственной эффективности. Задача для менеджмента – головоломная! Для нас потеря пары человеко-недель по причине индивидуальной безответственности – непозволительная роскошь.
Это реально сказывается на всех. На собственниках. На сотрудниках. А Вы мне говорите, что при всём вышесказанном, конкретный исполнитель, который протабанил и нарушил наши внутренние договорённости, не должен никоим образом лично ответить?
Слушайте, для меня этот спор – теоретический. Для нашей компании штраф – экзотика, к которой мы прибегаем в одном случае из сотни. Это бывает редко в совершенно исключительных и всем понятных случаях. Просто меня удивило последовательная инфантильная защита того, что менеджеры отвечают за всё и всегда виноваты во всём, а программисты ни за что не отвечают и никогда не виноваты ни в чём.
Я, правда, даже не верю, что писавшие комменты искренне придерживаются этой позиции.
Друзья! Работа над ошибками, которая приводит к улучшениям — это улица с двухсторонним движением. Хотите работать в правильной эффективной компании – не молчите! Говорите, что вас не устраивает. Помогайте стать лучше!
Я – за открытую честную позицию. Не правильно полагать, что вот моё дело маленькое – просто писать код. А о том, чтобы он был достойного качества, должно позаботиться начальство. Пусть не жалеет денег на тестировщиков и выстраивает процессы.
Парень, ты – не прав! Качество твоего кода больше всего зависит от тебя.
У нас в офисе есть простой рабочий по имени Альберт. Этот человек просто не может делать свою работу плохо. Чем бы он не занимался, ремонтом унитаза или покраской двери, он всё делает максимально ответственно и качественно. Этот человек вызывает моё восхищение!
Я не могу понять, когда коллеги приводят аргументы, оправдывающие плохую работу!
Мы постоянно совершенствуем свои процессы, но рассчитываем и на помощь и ответственность товарища, который не подведёт в нестандартной ситуации, не описанной в регламентах.
Когда-то у Друкера прочёл объяснение того, почему сержант американской армии так сильно придирается к новобранцам на счёт пуговиц, воротничков, начищенных сапог, обслуженного оружия и т.д. Он приучает солдата к тому, что незначимых мелочей нет. Потом что в условиях боя любая мелочь может стоить солдату жизни!!!
Мы провели в компании внутреннее исследование (мы не сидели с секундомером – это был просто опрос). Так вот: устранение среднестатистической ошибки, обнаруженной самим программистом при самотетсировании займёт у него в среднем 20 минут. Общие затраты рабочего времени в компании, если ошибку обнаружит тестировщик, уже 2 часа. Если же ошибка всплыла у Клиента, то среднестатистические затраты времени на повторение, описание, исправление – 60 часов!
Казалось бы, вывод ясен – максимальные инвестиции в раннее обнаружение ошибок. Но во что инвестировать? У нас есть тестовые планы и сценарии нагрузочного тестирования. Каждую ночь мы запускаем автотесты, равные по объёму 10 человеко-месяцам ручного тестирования. Но всё это – лишь вспомогательные функции. Ничего из этого не заменит ответственного отношения программиста к тому, что он отдаёт пользователям.
Всё просто. Мне кажется, что здесь не с чем спорить. НО, поскольку, комменты на хабре меня радуют, я готов продолжить.
Ещё раз на понимание. Я, прямо, вынужден оправдываться! За год штрафы были применены 1 раз и составили 5 % от месячной зарплаты.
Но коллеги! Вы действительно считаете, что не должны нести НИКАКОЙ ОТВЕТСТВЕННОСТИ?
Ща подолью масла в огонь. Статью я писал долго, несколько дней. А комментарии горячие. Где-то могут оказаться неполиткорректными.
Я совсем не утверждаю, что за менеджемент в компании отвечают программисты. Я просто пытался объяснить, что если Вы видите недостатки, то, естетственно, о них сказать (а не ждать, что они исчезнут сами собой по мановению волшебной палочки) и этим помочь их исправить. Лучший вариант для ускоренного развития – это сотрудничество всех, кому не всё равно. Программисты совершают ошибки, но могут исправить их, если им на них указать. И менеджеры тоже совершают ошибки. И тоже могут их исправить, если им показать, где они не правы.
Я, естественно, имею в виду правильных менеджеров и правильных программистов. Программиста, который вместо «Спасибо» за обнаруженный косяк и его исправления постарается замести мусор под ковёр и соскочить, нужно гнать поганой метлой из профессии.
Ровно тоже касается и менеджеров. Не нужно бояться увольнения за критику. В компании, где могут за это уволить, работать просто не стоит. У такой компании нет серьёзного будущего, поскольку в ней заблокирован базовый механизм самосовершенствования. Не нужно бояться увольнения из такой компании. Напротив, нужно самому энергично искать другую работу.
Что касается невыстроенных процессов, из-за которых Клиенту попал неоттестированный код, то любые процессы могут дать сбой, если участники нарушают технологию. Пусть выстроен совершенно правильный конвеер, но кто-то в цепочке недокручивает гайки. На выходе — брак. Любая технология состоит не только из набора процедур и правил, но и из решимости их выполнять. Нарушения способны похерить общий результат.
В описанном случае при обновлении у Клиента вылезла критическая проблема, которая не ловилась на тестовых данных. Её вынуждены были править на горячую. Стандартная технология осознанно нарушалась. Это могло бы пройти вполне нормально. У Клиента стоял бизнес, и он не готов был ждать официального выхода следующего релиза. Но, ЗАТО, готов был рискнуть. Надеясь, в том числе, на нашу сознательность.
В подобных случаях очень важно чувство личной ответственности, потому что оно, в значительной степени, компенсирует последствия нарушений правил выпуска. В критических случаях ваши коллеги имеют право рассчитывать на то, что вы делаете свою часть работы добросовестно. Я не вижу ничего военного в том, что вы разделите ответственность с другими за свою недоработку. В нашем случае наши сотрудники восприняли всё правильно – и я им за это благодарен. Они честно приняли отвественность на себя. И начали процесс планомерных улучшений, результатами которого я сегодня искренне впечатлён.
Ещё раз – штраф (огромная редкость и ЧП в нашей компании) был следствием откровенного нарушения правил. Это стоило многим людям бессонных ночей и больших переработок. Вы всерьёз полагаете, что наказаний за нарушения, приведшие к тяжким последствиям, быть не должно? Что можно отделаться словами о том, что виноват процесс, над которым нужно поработать всем?
Вот, например, водитель на дороге нарушил скоростной режим и сбил пешехода. Никаких инновационных методов регулирования скоростного режима не было применено, только знак «40» и «Осторожно — дети». Вы скажете, что нужно об общих процессах подумать, которые к этому привели, а виновника отпустить на восвояси? Нормально?
Я думаю, что надо и о процессах думать и об индивидуальной ответственности не забывать. Без такой индивидуальной ответственности вы далеко не уедете. Процессы лишь помогают людям более эффективно свою индивидуальную ответственность реализовать. Сама идея о том, что от индивидуальной ответственности нужно уходить, кажется мне ущербной.
Как бы ни было в мире мало хороших разработчиков. Иначе их станет ещё меньше!
То, что хороших разработчиков мало, не оправдывает раздолбайства и безответственности. Конечно, вас мало и вы вольны вести себя так, как вам заблагорассудится. А я волен давать этому свою этическую оценку. Я, к счастью, знаю очень хороших разработчиков, которым не придёт в голову утверждать, что человек, который по их милости провёл вечер с их глючной прогой вместо того, чтобы повозиться со своей маленькой дочуркой, ДОЛЖЕН ЭТО СМИРЕННО ТЕРПЕТЬ, ПОТОМУ ЧТО ХОРОШИХ РАЗРАБОТЧИКОВ МАЛО.
Я рад, что работаю с ними. Они прекрасно понимают, что от качества продуктов зависит личное время многих тысяч людей, их семейные отношения, их карьеры, их зарплата.
Что касается примера работы в Штатах, то американские компании существуют в условиях, заметно более мягких, чем мы. Просто переносить систему отношений на наши условия не получится, поскольку наши условия много жёстче. Их Клиенты обычно платят им, самое малое, 250$ за час работы специалиста. Нам же пока платят впятеро меньше.
Зарплаты же у нас пониже. Но не в разы. А всего лишь на десятки процентов. Зато затраты на оборудование повыше, чем в Штатах. А накладные, вследствие необходимости взаимодействовать с отечественной бюрократией, больше. Доходы много меньше, расходы заметно больше. Вряд ли мы можем в лоб применять американские бизнес модели и модели внутренних взаимоотношений. Мы ухитряемся жить и расти в предельно трудных условиях (как лишайник на севере), постоянно заботясь об увеличении собственной эффективности. Задача для менеджмента – головоломная! Для нас потеря пары человеко-недель по причине индивидуальной безответственности – непозволительная роскошь.
Это реально сказывается на всех. На собственниках. На сотрудниках. А Вы мне говорите, что при всём вышесказанном, конкретный исполнитель, который протабанил и нарушил наши внутренние договорённости, не должен никоим образом лично ответить?
Слушайте, для меня этот спор – теоретический. Для нашей компании штраф – экзотика, к которой мы прибегаем в одном случае из сотни. Это бывает редко в совершенно исключительных и всем понятных случаях. Просто меня удивило последовательная инфантильная защита того, что менеджеры отвечают за всё и всегда виноваты во всём, а программисты ни за что не отвечают и никогда не виноваты ни в чём.
Я, правда, даже не верю, что писавшие комменты искренне придерживаются этой позиции.
Друзья! Работа над ошибками, которая приводит к улучшениям — это улица с двухсторонним движением. Хотите работать в правильной эффективной компании – не молчите! Говорите, что вас не устраивает. Помогайте стать лучше!
Я – за открытую честную позицию. Не правильно полагать, что вот моё дело маленькое – просто писать код. А о том, чтобы он был достойного качества, должно позаботиться начальство. Пусть не жалеет денег на тестировщиков и выстраивает процессы.
Парень, ты – не прав! Качество твоего кода больше всего зависит от тебя.
У нас в офисе есть простой рабочий по имени Альберт. Этот человек просто не может делать свою работу плохо. Чем бы он не занимался, ремонтом унитаза или покраской двери, он всё делает максимально ответственно и качественно. Этот человек вызывает моё восхищение!
Я не могу понять, когда коллеги приводят аргументы, оправдывающие плохую работу!
Мы постоянно совершенствуем свои процессы, но рассчитываем и на помощь и ответственность товарища, который не подведёт в нестандартной ситуации, не описанной в регламентах.
Когда-то у Друкера прочёл объяснение того, почему сержант американской армии так сильно придирается к новобранцам на счёт пуговиц, воротничков, начищенных сапог, обслуженного оружия и т.д. Он приучает солдата к тому, что незначимых мелочей нет. Потом что в условиях боя любая мелочь может стоить солдату жизни!!!
Мы провели в компании внутреннее исследование (мы не сидели с секундомером – это был просто опрос). Так вот: устранение среднестатистической ошибки, обнаруженной самим программистом при самотетсировании займёт у него в среднем 20 минут. Общие затраты рабочего времени в компании, если ошибку обнаружит тестировщик, уже 2 часа. Если же ошибка всплыла у Клиента, то среднестатистические затраты времени на повторение, описание, исправление – 60 часов!
Казалось бы, вывод ясен – максимальные инвестиции в раннее обнаружение ошибок. Но во что инвестировать? У нас есть тестовые планы и сценарии нагрузочного тестирования. Каждую ночь мы запускаем автотесты, равные по объёму 10 человеко-месяцам ручного тестирования. Но всё это – лишь вспомогательные функции. Ничего из этого не заменит ответственного отношения программиста к тому, что он отдаёт пользователям.
Всё просто. Мне кажется, что здесь не с чем спорить. НО, поскольку, комменты на хабре меня радуют, я готов продолжить.
Ещё раз на понимание. Я, прямо, вынужден оправдываться! За год штрафы были применены 1 раз и составили 5 % от месячной зарплаты.
Но коллеги! Вы действительно считаете, что не должны нести НИКАКОЙ ОТВЕТСТВЕННОСТИ?
Голосом мистера Маки «Систематические штрафы и поиски козла отпущения это плохо — п’нятненько»
Ну в вашем конкретном случае если это было «один раз» и мы не знаем всех подробностей кто у вас там и как накосячил — то тут судить ваш поступок дело неблагодарное.
Хорошие разработчики никогда не уйдут бросив на полпути все изза обидной фразы или штрафа (на то они и «хорошие»)
а вот те кто косячат постоянно и у которых код выглядит и работает плохо — это не «хорошие» это какие то неправильные разработчики. От таких либо избавляться — либо сажать в пару с хорошим и пусть экстримят пока не переучатся — ну а если не переучатся то опять таки увольнять.
Если же накосячил хороший разработчик (а такое бывает — все мы люди) то уж поверьте он сам будет себя чувствовать очень виноватым и не уйдет домой пока не поправит.
Вот это ответственность. Ну а боязнь получить штраф это не ответственность — это мотивация страхом.
Да большинство задач которые стоят перед разработчиком делаются почти на автомате, типа новая формочка, экшн для ее обработки, пару новых полей в базу и тп, такие задачи разработчик сделает быстро и без хлопот независимо от настроения. Ну а реально сложные задачи где надо проявить смекалку сделать что то неординарное — задачи где нужна очень большая концентрация умственных способностей — эти задачи разработчик над которым не висит дамоклов меч сделает намного быстрее и качественнее чем тот кто боится штрафа, увольнения и проч.
Вообще все капризы разработчиков идут не от того что «нас мало но мы в тельняжках», а от как бы пафосно это не звучало от «обстановки, от вида из окна, от шума вокруг», и еще множества факторов которые мешают «творить».
Ну в вашем конкретном случае если это было «один раз» и мы не знаем всех подробностей кто у вас там и как накосячил — то тут судить ваш поступок дело неблагодарное.
Хорошие разработчики никогда не уйдут бросив на полпути все изза обидной фразы или штрафа (на то они и «хорошие»)
а вот те кто косячат постоянно и у которых код выглядит и работает плохо — это не «хорошие» это какие то неправильные разработчики. От таких либо избавляться — либо сажать в пару с хорошим и пусть экстримят пока не переучатся — ну а если не переучатся то опять таки увольнять.
Если же накосячил хороший разработчик (а такое бывает — все мы люди) то уж поверьте он сам будет себя чувствовать очень виноватым и не уйдет домой пока не поправит.
Вот это ответственность. Ну а боязнь получить штраф это не ответственность — это мотивация страхом.
Да большинство задач которые стоят перед разработчиком делаются почти на автомате, типа новая формочка, экшн для ее обработки, пару новых полей в базу и тп, такие задачи разработчик сделает быстро и без хлопот независимо от настроения. Ну а реально сложные задачи где надо проявить смекалку сделать что то неординарное — задачи где нужна очень большая концентрация умственных способностей — эти задачи разработчик над которым не висит дамоклов меч сделает намного быстрее и качественнее чем тот кто боится штрафа, увольнения и проч.
Вообще все капризы разработчиков идут не от того что «нас мало но мы в тельняжках», а от как бы пафосно это не звучало от «обстановки, от вида из окна, от шума вокруг», и еще множества факторов которые мешают «творить».
Sign up to leave a comment.
Программисты и менеджмент