Comments 59
Я уверен, что ключевым фактором должна стать ответственность - ответственность перед потребителем, которая в данный момент отсутствует. Примерно как в описаном примере из автомобильной индустрии. Когда топ-менеджмент фирмы выпускающей ПО начнёт отвечать за это ПО, причём отвечать достаточно серьёзно - вот тогда все остальные описанные в статье проблемы уйдут сами собой.
Это как у китайцев? Что-то потребителей у них не уменьшается, как раз наоборот :)
Алекс, а почему бы вам не высказаться более развернуто или здесь, или еще лучше в оригинальном посте на Technet. Вас ведь подоные темы интесуют, верно? А я бы поаплодировал умному мнению.
Я рассматриваю этот комментарий как попытку манипулирования и принуждения. :) Но, тем не менее, попробую чуть позже развёрнуто изложить свою мысль. Не думаю, что Вы найдёте там что-то новое для себя, но другим, возможно, будет полезно почитать.
Я последую Вашему примеру, и тоже погружусь в историю. Правда, не столь далёкую. Сам я это время не застал, но по отзывам абсолютно всех знакомых мне людей, заставших это время, в СССР качественнее всего работали при Сталине.
Можно, конечно, сказать, что в то время люди боялись, что ими двигал страх, и что это было ужасно. Но ведь и сейчас, когда Вы соглашаетесь работать overtime, и когда Вы соглашаетесь выпускать продукт "к определённому сроку" - Вами тоже движет страх. Страх потерять работу, страх попасть в чёрные списки и потерять профессию, страх выделиться из коллектива и подвергнуться острактизму... Возможно, кто-то придаёт громадное значение разнице между страхом попасть в лагеря и страхом потерять работу, но я этой разницы не вижу - ведь результат в обоих случаях одинаковый: Вы делаете то, что от Вас требуют.
При Сталине люди чувствовали ответственность, за то, что они делали. Если бы обрушился дом - сели бы все, и рабочие которые его строили, и архитектор. Сейчас уже так не строят... И сейчас, если обрушится дом, виноватых будут искать днём с огнём.
К сожалению, мне не удалось выяснить исторические корни возникновения такого понятия как "отказ от ответственности/гарантий", так же называемого "принципом as is", которое сопровождает программное обеспечение сколько я его помню. На мой взгляд, именно здесь находятся корни всех упомянутых в Вашей статье проблем. (Между прочим, далеко не все поступают именно так.)
Я не готов сию секунду решить все проблемы индустрии и предложить способ перехода от "as is" к нормальной, здоровой ответственности за свои действия. Надеюсь, Вы этого от меня и не ожидали. :) Но я абсолютно уверен, что именно эта проблема является ключевой, истинной причиной множества существующих в IT вторичных проблем, и что лечить надо именно причину, а не её следствия.
Сходя с тропы твёрдой уверенности на зыбкую почву теоретических предположений, можно отметить возможные пути реализации ответственности как обратной связи:
Можно, конечно, сказать, что в то время люди боялись, что ими двигал страх, и что это было ужасно. Но ведь и сейчас, когда Вы соглашаетесь работать overtime, и когда Вы соглашаетесь выпускать продукт "к определённому сроку" - Вами тоже движет страх. Страх потерять работу, страх попасть в чёрные списки и потерять профессию, страх выделиться из коллектива и подвергнуться острактизму... Возможно, кто-то придаёт громадное значение разнице между страхом попасть в лагеря и страхом потерять работу, но я этой разницы не вижу - ведь результат в обоих случаях одинаковый: Вы делаете то, что от Вас требуют.
При Сталине люди чувствовали ответственность, за то, что они делали. Если бы обрушился дом - сели бы все, и рабочие которые его строили, и архитектор. Сейчас уже так не строят... И сейчас, если обрушится дом, виноватых будут искать днём с огнём.
К сожалению, мне не удалось выяснить исторические корни возникновения такого понятия как "отказ от ответственности/гарантий", так же называемого "принципом as is", которое сопровождает программное обеспечение сколько я его помню. На мой взгляд, именно здесь находятся корни всех упомянутых в Вашей статье проблем. (Между прочим, далеко не все поступают именно так.)
Я не готов сию секунду решить все проблемы индустрии и предложить способ перехода от "as is" к нормальной, здоровой ответственности за свои действия. Надеюсь, Вы этого от меня и не ожидали. :) Но я абсолютно уверен, что именно эта проблема является ключевой, истинной причиной множества существующих в IT вторичных проблем, и что лечить надо именно причину, а не её следствия.
Сходя с тропы твёрдой уверенности на зыбкую почву теоретических предположений, можно отметить возможные пути реализации ответственности как обратной связи:
- Если Компания, выпустив продукт с дырой в безопасности, будет возмещать ущерб, как явный так и не явный, который понесли другие компании вследствие использования этого ПО (через которое их могли взломать и причинить громадные убытки, как финансовые так в плане репутации) - то Компания резко изменит своё отношение к time-based релизам.
- Если каждый Программист будет нести ответственность за свой код, например явно подписывая его своей цифровой подписью, и будет чётко понимать, что за первый баг в безопасности его сильно оштрафуют, а за второй уволят без права дальнейшей работы программистом - он будет писать совершенно иначе, и на попытки заставить его работать overtime будет посылать менеджера туда, куда Макар телят не гонял.Да, я утрирую, причём вполне сознательно - для наглядности! Да, далеко не всегда баг находится в одной точке кода, он может быть на стыке кода написанного разными программистами. Но за такие баги может отвечать архитектор системы. Да, часто один программист изменяет код другого - но в этом случае он может брать на себя ответственность за весь этот участок кода, и не подписывать его до тех пор, пока не будет в нём уверен. В общем, проблемы в предложенном подходе есть, их много, но, я верю, они вполне решаемые.
>>за первый баг в безопасности его сильно оштрафуют, а за второй уволят
>>без права дальнейшей работы программистом
Эдак вы за неделю всю группу разгоните :) Надо какие то промежуточные наказания ввести, например, мелкие телесные. И, кстати, где в вашей системе "кнута и пряника", собственно, сам пряник? Или это оригинальная система чистого кнута?
Я тоже утрирую для наглядности :) Основное правило ведь неизменно: кто платит - тот заказывает музыку, а программист просто "танцует" как может, он приходит в систему и работает по принципам, которые эта система ему диктует. А по ныненшним временам система диктует следуещее: быстрее, дешевле, ярче.
Хотя, возможно, с должности зам. директора мир видится несколько по иному ;)
>>без права дальнейшей работы программистом
Эдак вы за неделю всю группу разгоните :) Надо какие то промежуточные наказания ввести, например, мелкие телесные. И, кстати, где в вашей системе "кнута и пряника", собственно, сам пряник? Или это оригинальная система чистого кнута?
Я тоже утрирую для наглядности :) Основное правило ведь неизменно: кто платит - тот заказывает музыку, а программист просто "танцует" как может, он приходит в систему и работает по принципам, которые эта система ему диктует. А по ныненшним временам система диктует следуещее: быстрее, дешевле, ярче.
Хотя, возможно, с должности зам. директора мир видится несколько по иному ;)
Должность - фигня, был бы человек хороший... :)
Вы так уважительно это произносите: "система ему диктует"... А Вы не задумывались над тем, а кто диктует самой системе? Или Вы думаете, что система - это такой Бох, которому не диктует никто?
Мир очень велик и разнообразен, и в нём есть всё. Например, некоторые живут в мире, где идея отказаться от заработка на рассылке спама вызывает изумление, и многие клиенты просто не закажут дизайн если к нему не прилагается услуга по рассылке спама. А кто-то другой живёт в мире, где все вокруг проститутки.
Так и быть, я Вам, по секрету, открою самую главную тайну: системой командуете Вы сами. Вот Вы уверены, что сейчас необходимо "быстрее, дешевле, ярче". А я уверен, что сейчас необходимо "надёжно, безопасно, эффективно". Результат - кому нужно первое - заказывает у Вас. А кому второе - у меня. Причём и Вы и я недостатка в работе не испытываем. Вот такие дела...
Что касается пряников. Вы что, думаете программистам нравится в быстром темпе гнать халтуру? Или им нравятся overtime-ы? Если дать людям возможность нормально работать, для них это будет очень большой пряник.
Ну и насчёт разгона всей группы... А что Вы хотели, блин?! Вы что, думаете если заставлять всех годами работать "быстрее, дешевле, ярче", то потом эти же люди смогут начать писать качественно? Даже не надейтесь. Их придётся либо переучивать практически с нуля, либо заменять новыми, ещё не испорченными.
Да, если отказаться от "принципа as is" то 99.9% всех софтверных компаний просто лопнут, как мыльные пузыри. И 99.9% так называемых "программистов" останется без работы. Интересно получается, да?
Вы так уважительно это произносите: "система ему диктует"... А Вы не задумывались над тем, а кто диктует самой системе? Или Вы думаете, что система - это такой Бох, которому не диктует никто?
Мир очень велик и разнообразен, и в нём есть всё. Например, некоторые живут в мире, где идея отказаться от заработка на рассылке спама вызывает изумление, и многие клиенты просто не закажут дизайн если к нему не прилагается услуга по рассылке спама. А кто-то другой живёт в мире, где все вокруг проститутки.
Так и быть, я Вам, по секрету, открою самую главную тайну: системой командуете Вы сами. Вот Вы уверены, что сейчас необходимо "быстрее, дешевле, ярче". А я уверен, что сейчас необходимо "надёжно, безопасно, эффективно". Результат - кому нужно первое - заказывает у Вас. А кому второе - у меня. Причём и Вы и я недостатка в работе не испытываем. Вот такие дела...
Что касается пряников. Вы что, думаете программистам нравится в быстром темпе гнать халтуру? Или им нравятся overtime-ы? Если дать людям возможность нормально работать, для них это будет очень большой пряник.
Ну и насчёт разгона всей группы... А что Вы хотели, блин?! Вы что, думаете если заставлять всех годами работать "быстрее, дешевле, ярче", то потом эти же люди смогут начать писать качественно? Даже не надейтесь. Их придётся либо переучивать практически с нуля, либо заменять новыми, ещё не испорченными.
Да, если отказаться от "принципа as is" то 99.9% всех софтверных компаний просто лопнут, как мыльные пузыри. И 99.9% так называемых "программистов" останется без работы. Интересно получается, да?
>>Ну и насчёт разгона всей группы... А что Вы хотели, блин?!
Наказание и вознаграждение должны быть прямо пропорциональны. Если в результате успеха проекта вознаграждение программиста Х, менеджера 2*Х и т.д., то и наказание в случае неудачи должно быть в такой же пропорции. А у вас получается программиста/архитектора уволить, а тех кто над ним ... Ну за что их наказывать, нормальные вроде ребята. Потому и кажется, что рассуждаете вы уже с позиции управленца, хотя, наверное, человек вы и хороший :)
>>Да, если отказаться от "принципа as is" то 99.9% всех софтверных компаний просто лопнут,
>>как мыльные пузыри. И 99.9% так называемых "программистов" останется без работы. Интересно получается, да?
Дался вам этот "as is" :). Проекты которые делаются по контракту - там ответственность оговаривается в контракте, если же вы имеете ввиду фриварное или шареварное ПО, так по крайней мере честно предупредили. Или, купив программку за 10-20 баксов, вам не хватает потенциальной возможности снять с автора последнюю рубашку:) ? А подадите ли вы в суд на производителя дверных замков, если в вашу квартиру влезут воры (стоимость вполне сопоставима)? Вот если программа стоит дорого и там присутствует подобный дисклаймер - это повод задуматься, но в любом случае у покупателя есть свобода выбора.
Наказание и вознаграждение должны быть прямо пропорциональны. Если в результате успеха проекта вознаграждение программиста Х, менеджера 2*Х и т.д., то и наказание в случае неудачи должно быть в такой же пропорции. А у вас получается программиста/архитектора уволить, а тех кто над ним ... Ну за что их наказывать, нормальные вроде ребята. Потому и кажется, что рассуждаете вы уже с позиции управленца, хотя, наверное, человек вы и хороший :)
>>Да, если отказаться от "принципа as is" то 99.9% всех софтверных компаний просто лопнут,
>>как мыльные пузыри. И 99.9% так называемых "программистов" останется без работы. Интересно получается, да?
Дался вам этот "as is" :). Проекты которые делаются по контракту - там ответственность оговаривается в контракте, если же вы имеете ввиду фриварное или шареварное ПО, так по крайней мере честно предупредили. Или, купив программку за 10-20 баксов, вам не хватает потенциальной возможности снять с автора последнюю рубашку:) ? А подадите ли вы в суд на производителя дверных замков, если в вашу квартиру влезут воры (стоимость вполне сопоставима)? Вот если программа стоит дорого и там присутствует подобный дисклаймер - это повод задуматься, но в любом случае у покупателя есть свобода выбора.
Вы, к сожалению, меня не поняли. Если программист заверил своей цифровой подписью свой код - то его менеджер действительно не виноват, если в коде будут баги. Сейчас просто совершенно другая ситуация, программисты по сути не имеют права голоса, что и как надо делать им говорят менеджеры, поэтому результат зависит в большей степени именно от менеджеров. А в описанной мной ситуации программист просто пошлёт менеджера, и как раз потому, что не менеджер за код будет нести ответственность, а программист. Пример аналогичной ситуации - совсем недавно любой студент подрабатывающий в фирме без проблем ставил любой софт (не лицензии, понятное дело). А после того, как было несколько громких дел, и все поняли, что за установку этого софта отвечать будет тот, кто ставил, а не директор фирмы, которых на этом софте сэкономил - стало абсолютно нормальным отказываться от предложений поставить пиратский софт. Ибо на пустом месте и за копейки далеко не все готовы идти на преступление, даже при очень небольшой вероятности быть за него наказанным.
Что касается позиции управленца. Вот с этой позиции я ничего реального, такого что можно внедрять, предложить не могу. Если, на государственном уровне, примут закон об ответственности за ПО, то это может переломить ситуацию... хотя всё-равно будут пытаться выворачиваться всеми возможными способами, закон штука дырявая и глючная.
Если Вы не заметили, то я в своём комментарии дал ссылку не на фриварное/шароварное ПО, а на лицензию WinXP. Что касается проектов, выполняемых по контракту... я очень хорошо знаю и их качество, и гарантии, которые на них предоставляются. Давайте не будем о грустном.
Что касается позиции управленца. Вот с этой позиции я ничего реального, такого что можно внедрять, предложить не могу. Если, на государственном уровне, примут закон об ответственности за ПО, то это может переломить ситуацию... хотя всё-равно будут пытаться выворачиваться всеми возможными способами, закон штука дырявая и глючная.
Если Вы не заметили, то я в своём комментарии дал ссылку не на фриварное/шароварное ПО, а на лицензию WinXP. Что касается проектов, выполняемых по контракту... я очень хорошо знаю и их качество, и гарантии, которые на них предоставляются. Давайте не будем о грустном.
Я все прекрасно понял. Просто я уверен в том, что разрабатывание новых методик наказывания рядовых исполнителей ни к чему хорошему не ведет. Не будет никто никого никуда посылать. Нет, в частных случаях будут, в массе своей - нет. Вы же на Украине живете, слышали небось, как здесь с завидной регуляностью шахтеры гибнут. И что? Может и посылают, может и вслух, но все равно лезут в шахты. А ведь они не зарплатой или работой рискуют, а жизнью.
И с другой стороны, представте себе, как работать менеджером такого проекта, где все свободные художники, хотят работают, хотят посылают :)
А с лицензией WinXP- виноват, дейтвительно не обратил внимания :(
И с другой стороны, представте себе, как работать менеджером такого проекта, где все свободные художники, хотят работают, хотят посылают :)
А с лицензией WinXP- виноват, дейтвительно не обратил внимания :(
Вы считаете, что "ответственность" и "новая методика наказания" - это одно и то же? Или я Вас не понял?
Мне кажется, что не поняли. Я считаю, что воспитание отвественности через усиление наказания
вряд ли будет иметь длительный положительний эффект. Особенно в сфере творческих профессий.
Кроме того, любой толковый менеджер знает, кто в его группе пишет качественный код, а кто халтурит. Если менеджер не имеет возможности влиять на ситуацию в групе - проблема, скорее всего, находится выше
чем этот менеджер :) А дополнительный антураж в виде цифровой подписи с большей вероятностью буде использован для прикрытия задницы менеджера, чем для самозащиты программиста. ИМХО, конечно.
вряд ли будет иметь длительный положительний эффект. Особенно в сфере творческих профессий.
Кроме того, любой толковый менеджер знает, кто в его группе пишет качественный код, а кто халтурит. Если менеджер не имеет возможности влиять на ситуацию в групе - проблема, скорее всего, находится выше
чем этот менеджер :) А дополнительный антураж в виде цифровой подписи с большей вероятностью буде использован для прикрытия задницы менеджера, чем для самозащиты программиста. ИМХО, конечно.
Вы идиот.
это провокация? ;)
Нет. Пусть своего Сталина с его невероятным качеством труда засунет в жопу.
О! Теперь всё ясно. Вам просто Сталин не нравится. И если я упомянул его имя, то я - идиот, однозначно! :) Всё вполне логично.
Тем не менее, если Вы в состоянии осилить весь текст, то Вы заметите, что я нигде не утверждал, что Сталин - это хорошо. Я утверждал, что ответственность - это хорошо. Или для Вас ответственность и Сталин это синонимы, и Вы просто не представляете себе, как можно ответственно работать если Вам никто не угрожает лагерями?
Тем не менее, если Вы в состоянии осилить весь текст, то Вы заметите, что я нигде не утверждал, что Сталин - это хорошо. Я утверждал, что ответственность - это хорошо. Или для Вас ответственность и Сталин это синонимы, и Вы просто не представляете себе, как можно ответственно работать если Вам никто не угрожает лагерями?
Нет. А что, это похоже на провокацию? Это моё личное мнение. Готов аргументированно обсудить, если Вы готовы аргументированно возразить. :)
Начнём с рассмотрения высокотехнологичных товаров из дружественной КНДР как государства максимально близкого сталинскому СССР.
Я конечно тоже америку не открою, но проблема ж очевидно значительно сложнее - это относится и к посту и к Вашему комментарию. Заводя разговоры про плюсы тоталитарного управления Вы провоцируете неадекватную реакцию. Что касается ответственности Вы по сути правы. Однако стоит также признать что программист часто наоборот слишком многое берет на себя (далеко не всегда сам в силу "геройства")- он и аналитик, и архитектор, и тестер - так что чаще надо, наоборот, снимать ответственность. Именно снимать а не перекладывать (но мы эгоисты обычно норовим именно переложить). Ответственность должен брать на себя непосредственный менеджер команды или тим-лид. Ответственность за организацию процесса - а не сбрасывания тасков с последующей еблей мозга сделал-не-сделал. А для этого нужно быть в курсе, моделировать работу подчиненных, знать что как и почему делается, и отстаивать права и комфорт подчинённых - в противном случае лопух он, а не менеджер. И командно-административный момент "переключения" ответственности на высших уровнях иерархии должен быть компенсирован правильным менеджементом на нижних. И конечно не стоит путать это с анархией, коммунизмом, профсоюзами - как это иногда к сожалению видится сверху. Так что проблема нашей индустрии по-моему - очень низкое качество менеджмента нижнего звена. Причины простые - ну, главная, конечно, экономическая, однако не менее важная заключается в следующем. Для того, чтобы знать как и что надо быть в прошлом девелопером. Чтобы управлять успешно надо быть девелопером авторитетным (в нашей индустрии авторитет значит очень многое). Из тех, кто в теме, менеджментом работать почти никто не хочет, а если начнет - то большая часть потом сбегает назад. Со всеми вытекающими.
А Вы не хотите подумать, почему они сбегают назад, в программисты? Причём даже те, кто вполне успешно справлялся с работой менеджера?
Что касается ответственности, то проблема в том, что её никто брать не хочет вообще. А если кто, по молодости да наивности, её на себя возьмёт, то очень быстро обломается, когда столкнётся с окружающей его безответственностью у других.
Программист должен отвечать за свой код. За его качество, надёжность, безопасность, эффективность, соответствие спецификации... Менеджер должен отвечать за то, чтобы все возникающие в процессе работы вопросы решались быстро, чтобы его люди не простаивали, чтобы его людям никто не мешал работать, и т.д. Архитектор должен отвечать за то, что на стыке кода разных программистов и частей системы не будут возникать проблемы. Аналитик за то, что реализованная система действительно решает ту проблему клиента, для решения которой она вообще разрабатывалась.
А на практике всё совсем иначе. Программисты, архитекторы, аналитики не отвечают вообще ни за что. За них отвечает менеджер. В теории звучит логично - обычная иерархия, он отвечает за всё, следовательно дальше, с ответственностью своих подчинённых, он разберётся сам. А на практике всплывает любопытный нюанс: менеджер отвечает как правило только за то, чтобы сдать проект и получить за него деньги. Вот в этой точке и появляется известный подход "быстрее и дешевле".
Менеджеру, чтобы эффективно выполнять свою работу, необходимо уметь сдать клиенту то, что его команда наваяла. Причём чем меньше ресурсов будет потрачено на "ваяние" - тем лучше. Менеджер не отвечает ни за соответствие разработанного решения ожиданиям клиента, ни за безопасность кода... и, соответственно, не требует этого от своих людей - это обычная специфика иерархической системы.
Правда, если менеджер будет втюхивать клиентам полное говно, то эти клиенты больше не вернутся. Возникает проблема удержания клиентов. Но эту проблему, к сожалению, решают не повышением качества работы, а вылизыванием клиенту одного места: "любой каприз за ваши деньги". В результате клиент всё-равно получает говно, но остаётся доволен самим процессом разработки и надеется на дальнейшее плодотворное сотрудничество, в рамках которого, он уверен, из говна сделают конфетку!
Что касается ответственности, то проблема в том, что её никто брать не хочет вообще. А если кто, по молодости да наивности, её на себя возьмёт, то очень быстро обломается, когда столкнётся с окружающей его безответственностью у других.
Программист должен отвечать за свой код. За его качество, надёжность, безопасность, эффективность, соответствие спецификации... Менеджер должен отвечать за то, чтобы все возникающие в процессе работы вопросы решались быстро, чтобы его люди не простаивали, чтобы его людям никто не мешал работать, и т.д. Архитектор должен отвечать за то, что на стыке кода разных программистов и частей системы не будут возникать проблемы. Аналитик за то, что реализованная система действительно решает ту проблему клиента, для решения которой она вообще разрабатывалась.
А на практике всё совсем иначе. Программисты, архитекторы, аналитики не отвечают вообще ни за что. За них отвечает менеджер. В теории звучит логично - обычная иерархия, он отвечает за всё, следовательно дальше, с ответственностью своих подчинённых, он разберётся сам. А на практике всплывает любопытный нюанс: менеджер отвечает как правило только за то, чтобы сдать проект и получить за него деньги. Вот в этой точке и появляется известный подход "быстрее и дешевле".
Менеджеру, чтобы эффективно выполнять свою работу, необходимо уметь сдать клиенту то, что его команда наваяла. Причём чем меньше ресурсов будет потрачено на "ваяние" - тем лучше. Менеджер не отвечает ни за соответствие разработанного решения ожиданиям клиента, ни за безопасность кода... и, соответственно, не требует этого от своих людей - это обычная специфика иерархической системы.
Правда, если менеджер будет втюхивать клиентам полное говно, то эти клиенты больше не вернутся. Возникает проблема удержания клиентов. Но эту проблему, к сожалению, решают не повышением качества работы, а вылизыванием клиенту одного места: "любой каприз за ваши деньги". В результате клиент всё-равно получает говно, но остаётся доволен самим процессом разработки и надеется на дальнейшее плодотворное сотрудничество, в рамках которого, он уверен, из говна сделают конфетку!
Я, к сожалению, забыл выделить ключевой момент в предыдущем комментарии: менеджер отвечает только за то, чтобы сдать проект и получить за него деньги. Вот именно здесь и нехватает обратной связи - той самой ответственности перед клиентом, о которой изначально шла речь. Если компания будет отвечать конкретными деньгами за те же дыры в безопасности в своём продукте, то она быстро добавит ответственность за безопасность к обязанностям менеджера. А он добавит эту ответственность своим подчинённым. И только тогда приоритеты сдвинутся с "быстро, дёшево, как получится" на "не очень быстро, не очень дёшево, более-менее качественно".
Перед кем отвечать-то? Перед менеджером. Кто поймет, кто виноват и в чем дело? Как принять правильное решение в спорных моментах?
Потом Вы ж сами пишете что все проблемы решаются не качеством так вылизываением. Вылизать - проще и эффективнее. А качество - абстрактно, долго, нудно и вообще. Эффективность - величина измеряемая. А всё что про качество оно очень неформализуемо. Я не то чтоб совсем спорю... Но это вечные темы.
Почему сбегают назад - чего тут думать, ежу понятно. У тебя вместо спокойной работы верхней головой оказывается проблемы N сограждан у каждого свои тараканы а дело должно делаться. И да, когда ты понимаешь что вокруг полное распиздяйство многим хочется немедленно назад в спокойную жизнь. Психологически справиться сложно с постоянными "переключениями" с одной задачи на другую, становишься раздражительнее, чаще ловишь себя на том, что не пытаясь разобраться просто хочешь спихнуть задачу поскорее, чтоб думал сам и не лез, появляется куча полу-политических элементов... К тому же непонятно, нахер тебе это всё, если только сам не владелец - уровень оплаты если ты крутой девелопер отличается несильно :) И есть только один плюс, который перевешивает всё остальное - у тебя есть возможность делать, менять, усовершенствовать. Но снова - тем кто не сбежали назад свою очередь довольно тяжело оставаться в узких рамках тим-лидов, либо идут ещё дальше, либо открывают свое дело.
Потом Вы ж сами пишете что все проблемы решаются не качеством так вылизываением. Вылизать - проще и эффективнее. А качество - абстрактно, долго, нудно и вообще. Эффективность - величина измеряемая. А всё что про качество оно очень неформализуемо. Я не то чтоб совсем спорю... Но это вечные темы.
Почему сбегают назад - чего тут думать, ежу понятно. У тебя вместо спокойной работы верхней головой оказывается проблемы N сограждан у каждого свои тараканы а дело должно делаться. И да, когда ты понимаешь что вокруг полное распиздяйство многим хочется немедленно назад в спокойную жизнь. Психологически справиться сложно с постоянными "переключениями" с одной задачи на другую, становишься раздражительнее, чаще ловишь себя на том, что не пытаясь разобраться просто хочешь спихнуть задачу поскорее, чтоб думал сам и не лез, появляется куча полу-политических элементов... К тому же непонятно, нахер тебе это всё, если только сам не владелец - уровень оплаты если ты крутой девелопер отличается несильно :) И есть только один плюс, который перевешивает всё остальное - у тебя есть возможность делать, менять, усовершенствовать. Но снова - тем кто не сбежали назад свою очередь довольно тяжело оставаться в узких рамках тим-лидов, либо идут ещё дальше, либо открывают свое дело.
Хотелось бы добавить в ваш разговор из своего собственного опыта. Будучи менеджером на MS, я отвечал не только за выпуск, но и за то, что происходило после него. Например, после выпуска MSMQAdapter for BizTalk Server любая необходимость делать и выпускать патч скорее всего играла бы против меня. Конечно, это применимо лишь пока ты не сменил группу, но кто ж побежит из хорошей группы? Так что некоторая ответственность после релиза тоже имеется.
Я бы даже не сказал, что из менеджмента "бегут". Слово какой-то нехорошее, предполагает панику, страх, срочность. Обычно всего этого нет. Скажем, я пару лет прикидывал так и этак и спокойно с комфортом приглядывался к хорошим местами вокруг. Покидают менеджмент обычно с холодным умом и злым лихим весельем. К сожалению, часто лучшие. Наблюдал это, увы, не раз.
Я бы даже не сказал, что из менеджмента "бегут". Слово какой-то нехорошее, предполагает панику, страх, срочность. Обычно всего этого нет. Скажем, я пару лет прикидывал так и этак и спокойно с комфортом приглядывался к хорошим местами вокруг. Покидают менеджмент обычно с холодным умом и злым лихим весельем. К сожалению, часто лучшие. Наблюдал это, увы, не раз.
ну, тут мой опыт наверное ещё более экстремальный. мы занимаемся разработкой и поддержкой очень крупных веб-проектов. время жизни проекта - годы, релизов море, постоянные поиски, перемены, эксперименты, но главное, что когда ты это всё делаешь, ты до конца не знаешь как именно поведет себя всё при нагрузке - придет не миллион человек, а миллион двести и неожиданно твоя система просядет там, где вообще раньше думал всё в шоколаде. так что здесь скорее речь не об отвественности после релиза, а о постоянной ответственности :)
"читатили"="читали".
Спасибо за статью.
Спасибо за статью.
Согласен =) хорошая статья мне очень понравилась =)
спасибо. очень правильная, социальная так сказать, точка зрения рядового сотрудника.
но с другой стороны существует такие дисциплины, как проджект- и продакт-менеджмент.
так вот основной причиной событий, которые вы описали, является неправильный менеджмент.
а происходит потому что на позицию менеджмента приходят бывшие девелоперы, и «уж они то точно
знают», как правильно руководить проектом. — А на самом деле оказывается, что вместо того чтобы изучать собственно управление, они прессуют своих подчинённых, точно также, как когда то прессовали их.
но с другой стороны существует такие дисциплины, как проджект- и продакт-менеджмент.
так вот основной причиной событий, которые вы описали, является неправильный менеджмент.
а происходит потому что на позицию менеджмента приходят бывшие девелоперы, и «уж они то точно
знают», как правильно руководить проектом. — А на самом деле оказывается, что вместо того чтобы изучать собственно управление, они прессуют своих подчинённых, точно также, как когда то прессовали их.
Мой опыт работы в роли ПМ-ом говорит, что с ними-то как раз проблем особых нет, особенно из бывших девелоперов. Вообще-то, работа - дрянь, в несколько раз больше нервов и здоровья за ту же морковку на веревочке перед носом, но проблем особых с ними нет. А вот когда девелопера продвигают не в ПМ-ы, а в "лиды", или, Боже упаси, обычные менеджеры, вот тогда бывает идиотизм. Но это скорее из-за того, каких бывших девелоперов продвигают в менеджеры, чем из-за того, что они - девелоперы.
А забавно, статью заминусовали. Значит задевает! :-)
Её скорее заминусовали за слишком узкий подход.
Вообще говоря вопрос сверхурочных касается любой сферы. И многим менеджерам приходиться работать частенько больше, чем положено.
Что же касается сравнения с автомобильной промышленностью, то оно некорректно, так как в общем случае ошибка в программе не ведёт к человеческим жертвам.
Вообще говоря вопрос сверхурочных касается любой сферы. И многим менеджерам приходиться работать частенько больше, чем положено.
Что же касается сравнения с автомобильной промышленностью, то оно некорректно, так как в общем случае ошибка в программе не ведёт к человеческим жертвам.
Я говорил не про сверхурочные, а про выработку этики индустрии. Так что узка не статья, а ваше ее понимание. Я понимаю, что очень многим на Хабре такие темы просто непонятны и недоступны, но нетерпимость людей к непонятному показательна. А насчет "не ведет к человеческим жертвам"... Ну-ну. Вы встроенными системами не занимались, как я понимаю?
«сегодня я хотел бы предложить подумать о некоторых правилах, которые хорошо бы в ней иметь лет через сто... Начнем со сверурочных – overtime.»
Всё очень просто. Вы приводите пример. Сужая рассматриваемую область. В рамках этой области я вам указываю на ошибочность в привязывании к определённой индустрии. И собственно настаиваю на том, что данный пример не может относиться к статье с названием «Этика индустрии разработки софта»
По сути сверхурочные (неоплачиваемые) — есть нарушение этики бизнеса вообще.
Аналогично и по примеру с автопромом. Делать качественно — это этика любого бизнеса в принципе.
P. S. Если уж и рассматривать этику индустрии разработки софта, то скорее в направлении «нашёл уязвимость — сообщи конкуренту». То есть общее стремление к качеству. (Хотя неизвестно, может Боинг с Аэробусом тоже обмениваются критическими багами :-)
Всё очень просто. Вы приводите пример. Сужая рассматриваемую область. В рамках этой области я вам указываю на ошибочность в привязывании к определённой индустрии. И собственно настаиваю на том, что данный пример не может относиться к статье с названием «Этика индустрии разработки софта»
По сути сверхурочные (неоплачиваемые) — есть нарушение этики бизнеса вообще.
Аналогично и по примеру с автопромом. Делать качественно — это этика любого бизнеса в принципе.
P. S. Если уж и рассматривать этику индустрии разработки софта, то скорее в направлении «нашёл уязвимость — сообщи конкуренту». То есть общее стремление к качеству. (Хотя неизвестно, может Боинг с Аэробусом тоже обмениваются критическими багами :-)
И тут вы тоже заблуждаетесь. Есть индустрии, где сверхурочные не только считаются неэтичными, но и строго регулируются законами, по крайней мере в США (да, да, понимаю, какие там законы в России...) В софтверной и IT индустрии это не только не регулируется законами, но еще и в этику индустрии не вошло.
Насчет "сообщи конкуренту" - а чего ради сообщать конкуренту? Вот пользователям - это я понял бы. В конце концов, если Катерпиллар сделала плохой экскаватор, она не Джона Диэр предупреждает, а тех, кто этот экскаватор купил, правда?
Насчет "сообщи конкуренту" - а чего ради сообщать конкуренту? Вот пользователям - это я понял бы. В конце концов, если Катерпиллар сделала плохой экскаватор, она не Джона Диэр предупреждает, а тех, кто этот экскаватор купил, правда?
По-моему утверждение абсурдно. Уверен, что Трудовой кодекс в РФ (не знаю уж как там США), касается всех индустрий одновременно. Как вообще законы о труде могут регулировать индустрии по частям?
Про сообщи конкуренту — это лишь вектор формирования этики. Не нравится сообщать конкуренту — сообщайте пользователю :-) С другой стороны, это могло бы стать именно отличительной чертой IT индустрии. И в этом направлении надо работать.
Про сообщи конкуренту — это лишь вектор формирования этики. Не нравится сообщать конкуренту — сообщайте пользователю :-) С другой стороны, это могло бы стать именно отличительной чертой IT индустрии. И в этом направлении надо работать.
Это смотря какая программа. Есть такие программы, от которых жизнь человека зависит напрямую. Подумайте, какого рода программы пишутся для военных.
Анекдот в тему вспомнил. Сотрудник офиса стал приходить в 10 и уходить в 18, коллеги косо стали смотреть что-то не так, и уже ТРЕТИЙ ДЕНЬ.
А что это ты так рано уходишь? Обедаешь по часу, а не как все по 15 минут.
Ребят, вы че, я отпуске.
А что это ты так рано уходишь? Обедаешь по часу, а не как все по 15 минут.
Ребят, вы че, я отпуске.
Про time-based релизы повеселило :) В самом деле, если не ограничивать проекты по времени, они не выйдут никогда :) Или постоянно будут находиться в недоделанном состоянии. В этом проблема большинства opensource продуктов - где менеджмент отсутствует напрочь, как и сроки. Единицы успешных - Firefox, Ubuntu - как раз-таки четко соблюдают time-based релизы.
А вообще, почитайте про экстремальное программирование, Кента Бека чтоли, и по менеджменту чего-нибудь, а то как-то несерьезно даже.
А вообще, почитайте про экстремальное программирование, Кента Бека чтоли, и по менеджменту чего-нибудь, а то как-то несерьезно даже.
Что меня поражает в сентенциях на русском интернете, это необразованное высокомерие. Обязательно книжки почитать посоветуют, албанский поучить, причем без малейшего понимания как текущая жизнь устроена... Как по-вашему, как Гугл работает? Есть другие способы заставить людей доделывать проекты нежели ставить фиктивные сроки, как это обычно бывает. И даже сроки можно ставить по-разному. В общем, не считайте всех дураками, может и вас больше уважать будут?
Вот меня то же самое поражает. Узкий взгляд технаря, который плачется, как ему тяжело овертаймы работать и считающий менеджеров вокруг дураками, а сроки - злом. Может, Вы менеджмент тоже не признаете?
Витаминчик, я понимаю, что у вас сейчас по столу глюки бегают и вы с ними о чем-то очень интересном спорите. Только зачем по клавиатуре при этом стучать, да еще в комментариях к моей статье? Ни я, ни эта статья к тому что вы пишете никакого отношения не имеет. Если уж писать, то по теме, верно?
Эльдарчик, сказать нечего, так на личности переходим?
Я не хочу тебе ничего говорить. Ты пришел сюда хамить. Цитата: "Узкий взгляд технаря, который плачется" На нашей помойке это считалось хамством. Но даже не в этом дело: ты ведь даже статью не прочитал и ничего из нее не понял, а дальше начал всех строить. Ты ничего полезного не внес в дискуссию, ты отвлекаешь всех от дел (в том числе меня - делать мне нечего как с тобой бодаться) Делай это в других местах. Нам не о чем говорить. Теперь даже когда проспишься, я с тобой говорить не буду. Чао.
Хехехе... Вот так вот. Вы, Элдар, как-то удивились, зачем я в одном из комментариев Вам рассказал кое-что о себе и своём прошлом, как бы не по теме. А вот за этим. Господин 
vitamin
vitaminДа, не, не поможет. Агрессивных и тупых хамов на российском интернете, увы, очень много, они обычно даже и статью не читают толком, какой уж там профиль...
У вас тут культ личности, да?
Да нет, просто глупо смотрится Ваш комментарий по отношению к человеку, который много лет отработал и программистом, и менеджером в Microsoft.
Человек написал бред (имхо). Я высказал свои мысли по этому поводу. Или мне надо было с его биографией перед этим ознакомиться? :) Зачем? Я Диденко в свое время читать перестал, после того, как он в микрософт устроился.
С сотрудниками микрософта я пересекался не часто по роду деятельности, слава Богу. Зато много общался с сотрудниками циско. У этих двух компний много общего - например нетерпимость к любой критике в свой адрес. Это откладывает отпечаток и на сотрудников, видимо.
Действительно, о чем тут разговаривать.
С сотрудниками микрософта я пересекался не часто по роду деятельности, слава Богу. Зато много общался с сотрудниками циско. У этих двух компний много общего - например нетерпимость к любой критике в свой адрес. Это откладывает отпечаток и на сотрудников, видимо.
Действительно, о чем тут разговаривать.
Для себя я решил проблему довольно просто - релиз будет, а вот если не успеваем - значит просто выкинем то, что не успеваем. В крайнем случае мы пересмотрм план и _чуть_ задержимся (порядка недели), чтобы вылизать косяки, но не более. А в противном случае правда очень тяжело найти те самые способы "заставить" (мне не по душе термин, кстати) - причем включая самого себя. А какие конкретные методы Вы имели в виду?
Взгляните на мою статью про AIM (http://blogs.technet.com/eldar/archive/2…)
Почему команда начинает разрываться на части? Потому что соотношение кнут-пряник для команды и для менеджеров очень разные. Средний программист за релиз получает в лучшем случае табличку на стенку (или на спецподставку, как в MS), а верхний менеджер - повышение с очень ощутимыми материальными благами, за провал релиза программист почти не отвечает, а верхний менеджер - головой. За серьезные баги в выпущенном продукте наоборот отвечает больше программист, а менеджер так и остается с повышением по службе, в зарплате и все прочее. Этот перекос и разрывает команду.
Синхронизируйте награды и наказания по вертикали, и вся команда как единое целое будет либо жать к сроку (и выжмет, хотя и вопрос что), или фиксировать проблемы пока можно будет не стесняться продукта. Или что-то посередине. Чего из этих двух будет больше - зависит от высшего менеджмента, который будет балансировать награды и наказания. И именно он и должен решать, хотят они выпускать халтуру или нормальные продукты и сколько они готовы платить за качество.
На Гугле, например, премия не годовая, а по выпуску. Хочешь вылизывать - сиди без премии. То есть срок есть, стимул к выпуску в срок есть, но решение оставлено за командой. Это и отделяет от time-based releases иные, более качественные.
Почему команда начинает разрываться на части? Потому что соотношение кнут-пряник для команды и для менеджеров очень разные. Средний программист за релиз получает в лучшем случае табличку на стенку (или на спецподставку, как в MS), а верхний менеджер - повышение с очень ощутимыми материальными благами, за провал релиза программист почти не отвечает, а верхний менеджер - головой. За серьезные баги в выпущенном продукте наоборот отвечает больше программист, а менеджер так и остается с повышением по службе, в зарплате и все прочее. Этот перекос и разрывает команду.
Синхронизируйте награды и наказания по вертикали, и вся команда как единое целое будет либо жать к сроку (и выжмет, хотя и вопрос что), или фиксировать проблемы пока можно будет не стесняться продукта. Или что-то посередине. Чего из этих двух будет больше - зависит от высшего менеджмента, который будет балансировать награды и наказания. И именно он и должен решать, хотят они выпускать халтуру или нормальные продукты и сколько они готовы платить за качество.
На Гугле, например, премия не годовая, а по выпуску. Хочешь вылизывать - сиди без премии. То есть срок есть, стимул к выпуску в срок есть, но решение оставлено за командой. Это и отделяет от time-based releases иные, более качественные.
Вы затронули интересный момент. Мне всегда казалось что и в MS и в Гугле материальная компенсация у девелоперов, особенно проверенных и нужных, вполне себе ничего. Я ошибаюсь?
Что касается премий по выпуску - это гарантированные премии? Или всё-таки нет? То есть от чего они ещё зависят кроме даты релиза? Или когда бы какой релиз не вышел - будет премия?
Что касается премий по выпуску - это гарантированные премии? Или всё-таки нет? То есть от чего они ещё зависят кроме даты релиза? Или когда бы какой релиз не вышел - будет премия?
Компенсация, да, неплохая. Хотя, конечно, как посмотреть. Большинство и разработчиков, и ПМов, которые не "junior" ("младший", как в "младший научный сотрудник"), получают если прибавить бонусы и прочие халявы не менее 100 тыс. долл. в год. Правда включенные в эту сумму бонусы (если с начальством не поругался) и халявы (которые не совсем халявы, поскольку не зря называются "компенсация") немаленькие, сама зарплата часто поменьше. А средняя зарплата разработчика на MS вообще $118K/год. Это несравненно лучше, чем доходы, скажем, освобожденых работников хлопковых плантаций и их бывших хозяев где-нибудь в глубинке Теннесси. С другой стороны, другие фирмы тоже особо не жмотятся.
Насчет Гугла, насколько я слышал, типа когда бы релиз ни вышел. Собственно, тоже стимул ничего - премию-то ведь хочется, и не когда-нибудь, а если премия очень ощутимых размеров, то и тем более. Но врать не буду. Спрашивайте лучше моего бывшего дев менеджера - он сейчас как раз в Гугле работает, простым девелопером, кстати, по теме разговора. Хотя менеджер был отличный.
Насчет Гугла, насколько я слышал, типа когда бы релиз ни вышел. Собственно, тоже стимул ничего - премию-то ведь хочется, и не когда-нибудь, а если премия очень ощутимых размеров, то и тем более. Но врать не буду. Спрашивайте лучше моего бывшего дев менеджера - он сейчас как раз в Гугле работает, простым девелопером, кстати, по теме разговора. Хотя менеджер был отличный.
а то, что минусуют, кстати тоже очень интересный феномен. в статье действительно многое "слишком "просто", но это не повод.
Sign up to leave a comment.
Этика индустрии разработки софта