Ща подолью масла в огонь. Статью я писал долго, несколько дней. А комментарии горячие. Где-то могут оказаться неполиткорректными.
Я совсем не утверждаю, что за менеджемент в компании отвечают программисты. Я просто пытался объяснить, что если Вы видите недостатки, то, естетственно, о них сказать (а не ждать, что они исчезнут сами собой по мановению волшебной палочки) и этим помочь их исправить. Лучший вариант для ускоренного развития – это сотрудничество всех, кому не всё равно. Программисты совершают ошибки, но могут исправить их, если им на них указать. И менеджеры тоже совершают ошибки. И тоже могут их исправить, если им показать, где они не правы.
Я, естественно, имею в виду правильных менеджеров и правильных программистов. Программиста, который вместо «Спасибо» за обнаруженный косяк и его исправления постарается замести мусор под ковёр и соскочить, нужно гнать поганой метлой из профессии.
Ровно тоже касается и менеджеров. Не нужно бояться увольнения за критику. В компании, где могут за это уволить, работать просто не стоит. У такой компании нет серьёзного будущего, поскольку в ней заблокирован базовый механизм самосовершенствования. Не нужно бояться увольнения из такой компании. Напротив, нужно самому энергично искать другую работу.
Что касается невыстроенных процессов, из-за которых Клиенту попал неоттестированный код, то любые процессы могут дать сбой, если участники нарушают технологию. Пусть выстроен совершенно правильный конвеер, но кто-то в цепочке недокручивает гайки. На выходе — брак. Любая технология состоит не только из набора процедур и правил, но и из решимости их выполнять. Нарушения способны похерить общий результат.
В описанном случае при обновлении у Клиента вылезла критическая проблема, которая не ловилась на тестовых данных. Её вынуждены были править на горячую. Стандартная технология осознанно нарушалась. Это могло бы пройти вполне нормально. У Клиента стоял бизнес, и он не готов был ждать официального выхода следующего релиза. Но, ЗАТО, готов был рискнуть. Надеясь, в том числе, на нашу сознательность.
В подобных случаях очень важно чувство личной ответственности, потому что оно, в значительной степени, компенсирует последствия нарушений правил выпуска. В критических случаях ваши коллеги имеют право рассчитывать на то, что вы делаете свою часть работы добросовестно. Я не вижу ничего военного в том, что вы разделите ответственность с другими за свою недоработку. В нашем случае наши сотрудники восприняли всё правильно – и я им за это благодарен. Они честно приняли отвественность на себя. И начали процесс планомерных улучшений, результатами которого я сегодня искренне впечатлён.
Ещё раз – штраф (огромная редкость и ЧП в нашей компании) был следствием откровенного нарушения правил. Это стоило многим людям бессонных ночей и больших переработок. Вы всерьёз полагаете, что наказаний за нарушения, приведшие к тяжким последствиям, быть не должно? Что можно отделаться словами о том, что виноват процесс, над которым нужно поработать всем?
Вот, например, водитель на дороге нарушил скоростной режим и сбил пешехода. Никаких инновационных методов регулирования скоростного режима не было применено, только знак «40» и «Осторожно — дети». Вы скажете, что нужно об общих процессах подумать, которые к этому привели, а виновника отпустить на восвояси? Нормально?
Я думаю, что надо и о процессах думать и об индивидуальной ответственности не забывать. Без такой индивидуальной ответственности вы далеко не уедете. Процессы лишь помогают людям более эффективно свою индивидуальную ответственность реализовать. Сама идея о том, что от индивидуальной ответственности нужно уходить, кажется мне ущербной.
Как бы ни было в мире мало хороших разработчиков. Иначе их станет ещё меньше!
То, что хороших разработчиков мало, не оправдывает раздолбайства и безответственности. Конечно, вас мало и вы вольны вести себя так, как вам заблагорассудится. А я волен давать этому свою этическую оценку. Я, к счастью, знаю очень хороших разработчиков, которым не придёт в голову утверждать, что человек, который по их милости провёл вечер с их глючной прогой вместо того, чтобы повозиться со своей маленькой дочуркой, ДОЛЖЕН ЭТО СМИРЕННО ТЕРПЕТЬ, ПОТОМУ ЧТО ХОРОШИХ РАЗРАБОТЧИКОВ МАЛО.
Я рад, что работаю с ними. Они прекрасно понимают, что от качества продуктов зависит личное время многих тысяч людей, их семейные отношения, их карьеры, их зарплата.
Что касается примера работы в Штатах, то американские компании существуют в условиях, заметно более мягких, чем мы. Просто переносить систему отношений на наши условия не получится, поскольку наши условия много жёстче. Их Клиенты обычно платят им, самое малое, 250$ за час работы специалиста. Нам же пока платят впятеро меньше.
Зарплаты же у нас пониже. Но не в разы. А всего лишь на десятки процентов. Зато затраты на оборудование повыше, чем в Штатах. А накладные, вследствие необходимости взаимодействовать с отечественной бюрократией, больше. Доходы много меньше, расходы заметно больше. Вряд ли мы можем в лоб применять американские бизнес модели и модели внутренних взаимоотношений. Мы ухитряемся жить и расти в предельно трудных условиях (как лишайник на севере), постоянно заботясь об увеличении собственной эффективности. Задача для менеджмента – головоломная! Для нас потеря пары человеко-недель по причине индивидуальной безответственности – непозволительная роскошь.
Это реально сказывается на всех. На собственниках. На сотрудниках. А Вы мне говорите, что при всём вышесказанном, конкретный исполнитель, который протабанил и нарушил наши внутренние договорённости, не должен никоим образом лично ответить?
Слушайте, для меня этот спор – теоретический. Для нашей компании штраф – экзотика, к которой мы прибегаем в одном случае из сотни. Это бывает редко в совершенно исключительных и всем понятных случаях. Просто меня удивило последовательная инфантильная защита того, что менеджеры отвечают за всё и всегда виноваты во всём, а программисты ни за что не отвечают и никогда не виноваты ни в чём.
Я, правда, даже не верю, что писавшие комменты искренне придерживаются этой позиции.
Друзья! Работа над ошибками, которая приводит к улучшениям — это улица с двухсторонним движением. Хотите работать в правильной эффективной компании – не молчите! Говорите, что вас не устраивает. Помогайте стать лучше!
Я – за открытую честную позицию. Не правильно полагать, что вот моё дело маленькое – просто писать код. А о том, чтобы он был достойного качества, должно позаботиться начальство. Пусть не жалеет денег на тестировщиков и выстраивает процессы.
Парень, ты – не прав! Качество твоего кода больше всего зависит от тебя.
У нас в офисе есть простой рабочий по имени Альберт. Этот человек просто не может делать свою работу плохо. Чем бы он не занимался, ремонтом унитаза или покраской двери, он всё делает максимально ответственно и качественно. Этот человек вызывает моё восхищение!
Я не могу понять, когда коллеги приводят аргументы, оправдывающие плохую работу!
Мы постоянно совершенствуем свои процессы, но рассчитываем и на помощь и ответственность товарища, который не подведёт в нестандартной ситуации, не описанной в регламентах.
Когда-то у Друкера прочёл объяснение того, почему сержант американской армии так сильно придирается к новобранцам на счёт пуговиц, воротничков, начищенных сапог, обслуженного оружия и т.д. Он приучает солдата к тому, что незначимых мелочей нет. Потом что в условиях боя любая мелочь может стоить солдату жизни!!!
Мы провели в компании внутреннее исследование (мы не сидели с секундомером – это был просто опрос). Так вот: устранение среднестатистической ошибки, обнаруженной самим программистом при самотетсировании займёт у него в среднем 20 минут. Общие затраты рабочего времени в компании, если ошибку обнаружит тестировщик, уже 2 часа. Если же ошибка всплыла у Клиента, то среднестатистические затраты времени на повторение, описание, исправление – 60 часов!
Казалось бы, вывод ясен – максимальные инвестиции в раннее обнаружение ошибок. Но во что инвестировать? У нас есть тестовые планы и сценарии нагрузочного тестирования. Каждую ночь мы запускаем автотесты, равные по объёму 10 человеко-месяцам ручного тестирования. Но всё это – лишь вспомогательные функции. Ничего из этого не заменит ответственного отношения программиста к тому, что он отдаёт пользователям.
Всё просто. Мне кажется, что здесь не с чем спорить. НО, поскольку, комменты на хабре меня радуют, я готов продолжить.
Ещё раз на понимание. Я, прямо, вынужден оправдываться! За год штрафы были применены 1 раз и составили 5 % от месячной зарплаты.
Но коллеги! Вы действительно считаете, что не должны нести НИКАКОЙ ОТВЕТСТВЕННОСТИ?
Ща подолью масла в огонь. Статью я писал долго, несколько дней. А комментарии горячие. Где-то могут оказаться неполиткорректными.
Я совсем не утверждаю, что за менеджемент в компании отвечают программисты. Я просто пытался объяснить, что если Вы видите недостатки, то, естетственно, о них сказать (а не ждать, что они исчезнут сами собой по мановению волшебной палочки) и этим помочь их исправить. Лучший вариант для ускоренного развития – это сотрудничество всех, кому не всё равно. Программисты совершают ошибки, но могут исправить их, если им на них указать. И менеджеры тоже совершают ошибки. И тоже могут их исправить, если им показать, где они не правы.
Я, естественно, имею в виду правильных менеджеров и правильных программистов. Программиста, который вместо «Спасибо» за обнаруженный косяк и его исправления постарается замести мусор под ковёр и соскочить, нужно гнать поганой метлой из профессии.
Ровно тоже касается и менеджеров. Не нужно бояться увольнения за критику. В компании, где могут за это уволить, работать просто не стоит. У такой компании нет серьёзного будущего, поскольку в ней заблокирован базовый механизм самосовершенствования. Не нужно бояться увольнения из такой компании. Напротив, нужно самому энергично искать другую работу.
Что касается невыстроенных процессов, из-за которых Клиенту попал неоттестированный код, то любые процессы могут дать сбой, если участники нарушают технологию. Пусть выстроен совершенно правильный конвеер, но кто-то в цепочке недокручивает гайки. На выходе — брак. Любая технология состоит не только из набора процедур и правил, но и из решимости их выполнять. Нарушения способны похерить общий результат.
В описанном случае при обновлении у Клиента вылезла критическая проблема, которая не ловилась на тестовых данных. Её вынуждены были править на горячую. Стандартная технология осознанно нарушалась. Это могло бы пройти вполне нормально. У Клиента стоял бизнес, и он не готов был ждать официального выхода следующего релиза. Но, ЗАТО, готов был рискнуть. Надеясь, в том числе, на нашу сознательность.
В подобных случаях очень важно чувство личной ответственности, потому что оно, в значительной степени, компенсирует последствия нарушений правил выпуска. В критических случаях ваши коллеги имеют право рассчитывать на то, что вы делаете свою часть работы добросовестно. Я не вижу ничего военного в том, что вы разделите ответственность с другими за свою недоработку. В нашем случае наши сотрудники восприняли всё правильно – и я им за это благодарен. Они честно приняли отвественность на себя. И начали процесс планомерных улучшений, результатами которого я сегодня искренне впечатлён.
Ещё раз – штраф (огромная редкость и ЧП в нашей компании) был следствием откровенного нарушения правил. Это стоило многим людям бессонных ночей и больших переработок. Вы всерьёз полагаете, что наказаний за нарушения, приведшие к тяжким последствиям, быть не должно? Что можно отделаться словами о том, что виноват процесс, над которым нужно поработать всем?
Вот, например, водитель на дороге нарушил скоростной режим и сбил пешехода. Никаких инновационных методов регулирования скоростного режима не было применено, только знак «40» и «Осторожно — дети». Вы скажете, что нужно об общих процессах подумать, которые к этому привели, а виновника отпустить на восвояси? Нормально?
Я думаю, что надо и о процессах думать и об индивидуальной ответственности не забывать. Без такой индивидуальной ответственности вы далеко не уедете. Процессы лишь помогают людям более эффективно свою индивидуальную ответственность реализовать. Сама идея о том, что от индивидуальной ответственности нужно уходить, кажется мне ущербной.
Как бы ни было в мире мало хороших разработчиков. Иначе их станет ещё меньше!
То, что хороших разработчиков мало, не оправдывает раздолбайства и безответственности. Конечно, вас мало и вы вольны вести себя так, как вам заблагорассудится. А я волен давать этому свою этическую оценку. Я, к счастью, знаю очень хороших разработчиков, которым не придёт в голову утверждать, что человек, который по их милости провёл вечер с их глючной прогой вместо того, чтобы повозиться со своей маленькой дочуркой, ДОЛЖЕН ЭТО СМИРЕННО ТЕРПЕТЬ, ПОТОМУ ЧТО ХОРОШИХ РАЗРАБОТЧИКОВ МАЛО.
Я рад, что работаю с ними. Они прекрасно понимают, что от качества продуктов зависит личное время многих тысяч людей, их семейные отношения, их карьеры, их зарплата.
Что касается примера работы в Штатах, то американские компании существуют в условиях, заметно более мягких, чем мы. Просто переносить систему отношений на наши условия не получится, поскольку наши условия много жёстче. Их Клиенты обычно платят им, самое малое, 250$ за час работы специалиста. Нам же пока платят впятеро меньше.
Зарплаты же у нас пониже. Но не в разы. А всего лишь на десятки процентов. Зато затраты на оборудование повыше, чем в Штатах. А накладные, вследствие необходимости взаимодействовать с отечественной бюрократией, больше. Доходы много меньше, расходы заметно больше. Вряд ли мы можем в лоб применять американские бизнес модели и модели внутренних взаимоотношений. Мы ухитряемся жить и расти в предельно трудных условиях (как лишайник на севере), постоянно заботясь об увеличении собственной эффективности. Задача для менеджмента – головоломная! Для нас потеря пары человеко-недель по причине индивидуальной безответственности – непозволительная роскошь.
Это реально сказывается на всех. На собственниках. На сотрудниках. А Вы мне говорите, что при всём вышесказанном, конкретный исполнитель, который протабанил и нарушил наши внутренние договорённости, не должен никоим образом лично ответить?
Слушайте, для меня этот спор – теоретический. Для нашей компании штраф – экзотика, к которой мы прибегаем в одном случае из сотни. Это бывает редко в совершенно исключительных и всем понятных случаях. Просто меня удивило последовательная инфантильная защита того, что менеджеры отвечают за всё и всегда виноваты во всём, а программисты ни за что не отвечают и никогда не виноваты ни в чём.
Я, правда, даже не верю, что писавшие комменты искренне придерживаются этой позиции.
Друзья! Работа над ошибками, которая приводит к улучшениям — это улица с двухсторонним движением. Хотите работать в правильной эффективной компании – не молчите! Говорите, что вас не устраивает. Помогайте стать лучше!
Я – за открытую честную позицию. Не правильно полагать, что вот моё дело маленькое – просто писать код. А о том, чтобы он был достойного качества, должно позаботиться начальство. Пусть не жалеет денег на тестировщиков и выстраивает процессы.
Парень, ты – не прав! Качество твоего кода больше всего зависит от тебя.
У нас в офисе есть простой рабочий по имени Альберт. Этот человек просто не может делать свою работу плохо. Чем бы он не занимался, ремонтом унитаза или покраской двери, он всё делает максимально ответственно и качественно. Этот человек вызывает моё восхищение!
Я не могу понять, когда коллеги приводят аргументы, оправдывающие плохую работу!
Мы постоянно совершенствуем свои процессы, но рассчитываем и на помощь и ответственность товарища, который не подведёт в нестандартной ситуации, не описанной в регламентах.
Когда-то у Друкера прочёл объяснение того, почему сержант американской армии так сильно придирается к новобранцам на счёт пуговиц, воротничков, начищенных сапог, обслуженного оружия и т.д. Он приучает солдата к тому, что незначимых мелочей нет. Потом что в условиях боя любая мелочь может стоить солдату жизни!!!
Мы провели в компании внутреннее исследование (мы не сидели с секундомером – это был просто опрос). Так вот: устранение среднестатистической ошибки, обнаруженной самим программистом при самотетсировании займёт у него в среднем 20 минут. Общие затраты рабочего времени в компании, если ошибку обнаружит тестировщик, уже 2 часа. Если же ошибка всплыла у Клиента, то среднестатистические затраты времени на повторение, описание, исправление – 60 часов!
Казалось бы, вывод ясен – максимальные инвестиции в раннее обнаружение ошибок. Но во что инвестировать? У нас есть тестовые планы и сценарии нагрузочного тестирования. Каждую ночь мы запускаем автотесты, равные по объёму 10 человеко-месяцам ручного тестирования. Но всё это – лишь вспомогательные функции. Ничего из этого не заменит ответственного отношения программиста к тому, что он отдаёт пользователям.
Всё просто. Мне кажется, что здесь не с чем спорить. НО, поскольку, комменты на хабре меня радуют, я готов продолжить.
Ещё раз на понимание. Я, прямо, вынужден оправдываться! За год штрафы были применены 1 раз и составили 5 % от месячной зарплаты.
Но коллеги! Вы действительно считаете, что не должны нести НИКАКОЙ ОТВЕТСТВЕННОСТИ?