Share via

Этика индустрии разработки софта

  • Article

?????-???? ? ????? ????????????? ?????
-----

????????? ?????????? ????? ??? ????? ??????. ?????? ???, ????? ????????? ????? ???????? ??? ?????????, ??????????? ?????????? ?????? ??? ??? ?????????? ???????????? ??? ??????? ???? ???????, ??????? ??? ?? ????? ??????? ? ????? ??? ????????????????. ?????, ????????? ?????? ?????????? ???????????? ?????????? ????? , ????? ?????? ? ???, ??? ????? ?????? ? ??? ????? ?????. ? ????? ???????? ?????????? ??????? ????? ??????? ???? ???? ? ?????? , ?? ???? ??, ??? ?????????? ?? ?????? ???????? ??? ????????, ?? ? ? ???? ??? ?????????? ????? ??????.

????????, ? ?????? ???????????? ??? ??? ?????? ?????????????. ??? ??? ???????? ???? ?? ? ???? ?? ???????? ?? ???????? ??????. ??, ??, ??????????? ?????? ?????? ??, ??????, ?? ?????? ?? ? ???. ??, ??????, ??? ???????? ?????? ?????????? ????? ? ?????, ? ?? ? recycling/??????????. ??????????, ??????????? ?????? ?????????? ????? ? ????? ?????? ?????????? ???-?????? ? ???????? ?????? ??????? ???? ??????? ???????????? ????????? (? ?? ? ?????), ??? ???????? ? ??? ?? ?????? ???????? ??????????????-????, ??????, ?? ??????? ?????? ??????? ???????. ?? ? ??????? ??????? ??????? ??? ????????? ?????, ?????????? ???????? ????? ?? ??????????? ?????????? ???? ?????????? ??????. ?? ????????? ????? ???????? ???? ???????? ??? ???? ???????? ?? ??????.

???????, ?? ??????????. ??? ???, sofware ????????? ??? ????? ??????, ?? ????? ??? ?????? ???????????, ? ??????? ? ????? ?? ?????????? ???????? ? ????????? ????????, ??????? ?????? ?? ? ??? ????? ??? ????? ???...

?????? ?? ??????????? – overtime. ??????-??, ???? ??????, ?????????????? ???????????? – ??? ?????????. ????? ?????? ?????? ????? ????? ?????. ? ?????????, ???????????? ??? ?? ?????????????? ? ????????? ?????????? ????? ? ?????? IT, ??? ??? ???? ?????????????? ?? ?????????? ??????????? ?????? ??????? ????? ???????? ????? ??? ????? ? ?????? ???????? ????????. ???? ????, ? ??????????? ???? ???? ? ?????? ????? ?? ??? ????? – ???????? ???????????? ?????????????? ???????????? ??? ???????? ?????????, ??? ???????? ?????? ?????????? ?????? ? ???????????.

???????, ???? ???????????? (?????????, ??????, ???? ???????), ??? ???????????? ?? ????? ???? ?? ??????????? ?????????????????? ?????????????, ?? ???? ??? ?????? ?? ??????? ???????????... ??? ????????, ??????? ???????? ????? ??? ? ???? ???????? ?????? ??? ??????? ?? ??? ????????, ??? ???? ? ?????? ?????????. ??, ??? ?????? ?????? ???????? ? ?????? ???????????.

?? ??? ??? ? ?????????? ???????? ? ?? ????????, ??? ?????????-?????????, freeloaders, ??????? ?? ?????? ????????? ????? ???????? ?? 10-12 ????? ? ????, ?? ??? ? ??????? ??? ??????? ? ?? ??????? ??????? ???????????. ????? ???? ???????? ?? ??? ??? ??? ? ???? ?? ?????, ??? ???????? ????? ?????? ???? ???. ?????? ??????????? ?????????????? ?? ??????, ???? ?? ????????. ????? ????????? ???? ??????????????? ??????? ????? ??????? ????????, ???, ??????, ???????? ?????????????? ?????? ????????, ??? ????? ??????? ?????? ?????. ??, ??? ?? ???????????? ???, ??? ??? ????????, ?? ???? ?? ?????. ? ??? ???????, ??? ?? ?? ??????????. ???? ?? ???, ??? ??? ???????? ?????? – ??? ???????? ???????? ?? ??????... ??? ???????, ???? ????????? ?????? ????????? ?? ?????????, ????? ??? ?????????????? ?? ? ?????????? ???????? ? ??????, ???? ?????? ?? ?????????.

?????? ???????????? ?????? ????? ?????????, ??????? ? ?????, ?????? ? ???????? ??????????????? ? ???? ??? ??????? ??????????, ??? ?????? ????????? ?? ??????, ??? ??? ????, ? ???????????? ???? – time-based releases. ???? ?? ?????? ??? ?????? ??? AIM – ??? ???????, ??? ??????? ????????? ? ?????. ?????? ????????? ? ????? – ??? ??????? ???? ???????? ???????????? ???????????, ??? ??????? ?????????? ????????, ??? ??????? ?????? ???????? ??????????? ? ?????????? ? ?????????? ????????????? ??????, ???? ???? ??????? ????? ? ???. ? ????????????? ????????? – ???????, ??? ??? ???????????, ?? ??? ??? ?????? ????????? ????? – ?? ?????? ????????, ??????????? ???????, ?? ? ????? ????? ????? ?? ?? ??? ??? ??? ? ? ??????. ? ????????? ?? ????? ??? ???? ??? ?????????????? ??? ??????? ????.

? ??? ???, ??? ???????, ?????? ????? ? ????? ?????????? ????? ?, ????? ???? ????, ? ??????????????? ?????

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    Сереж, я тоже работаю overtime и не жалуюсь. Аргумент насчет высоких зарплат имеет некоторую валидность, но неполную. Индустрия платит такие зарплаты вовсе не от того, что компенсирует сверхурочные, а потому что дешевле найти не может. Открой полностью квоты на H1 визы и ты тоже будешь работать за $42K/year, причем с теми же сверхурочными. А то и меньше. Но главное в том, что вопрос-то был в другом - в этике и нормах индустрии. Рабочие на заводах Форда тоже считались соседями "везунчиками" с хорошей зарплатой и стабильной работой. Кроме того рассмотри такие вопросы:
  1. Эти зарплаты включают в себя неограниченные сверхурочные? Контракт может стыдливо упоминать, что ты "exempt", то есть тебе за работу сверх восьми часов не платят, но я еще не видел контракта, который говорил о хотя бы десятичасовом рабочем дне. Все так же стыдливо лопочут что-то о восьми. В крайнем случае, тебя на интервью предупредят, что "бывает" (как у меня было на интервью в IBM, а до этого на предыдущем месте работы в консалтинге -- где, кстати, сверхурочные оплачивали, так что я им был вполне рад). То есть ложь встроена в систему, а значит что-то с ней не так.
  2. А правильно ли заставлять людей работать сверх времени? Настоящая эффективность программиста в день обычно даже меньше восьми часов, но с митингами и накладными расходами это еще можно понять. А то, что сверх, приносит это пользу или вред проекту? Кстати, это не только программистов касается, но и менеджеров.
  3. Как это влияет на качество продукции и потребителя? Как это (в том числе, связанные с этим burnout и attrition) влияет на shareholders? Ответы на эти вопросы далеко не так тривиальны, как может показаться менеджеру с завода Форда начала прошлого века. Равно как и некоторым современным менеджерам.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    To SergeyS: Знаешь, по здравому размышлению я и второй пункт в твоем #1 не одобряю. Ты хочешь чтобы твоя команда была competitive или collaborative? Подробнее на твоем блоге скажу, а еще подробнее потом здесь отдельной статьей...

  • Anonymous
    January 01, 2003
    Я думаю мы понимаем термин ПМ по-разному. ПМы, о которых я пишу, не имеют возможностей заставить людей придти на работу сверхурочно, не имеют особой власти в выборе новых сотрудников и ни шиша не получают, если продукт успешен. То, что вы называете "ПМ", очень смахивает на обычных менеджеров, которые обычно и инициируют и культуру страха и сверхурочные. А в остальном, с этой поправкой, звучит очень даже разумно.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Dart, что вы сверхурочно не работаете - молодец, это правильно. Насчет этики вы не разобрались. Но не огорчайтесь, вы в большинстве. Уж слишком академический вопрос я поднял в изрядно технической аудитории. Вот запусти это я выпускникам какого-нибудь Гарварда в области Arts... Насчет не time-based releases, да, это не всегда возможно и, главное, пока что почти никому непонятно. Ну, как первобытный человек не понимал как это можно от огня не убегать. Пока кто-то не понял. И уверяю вас, его соплеменники долго били его по голове и остальным частям тела, пока до них не дошло какая это удобная штука, если знать как с ним обращаться. Если честно, я совсем не уверен, что это Зевс Прометея к скале приковал... Да, не time-based releases - это очень непросто. Но если вы умеете, это дает значительно лучший результат. Кстати, часто и с точки зрения "time". В общем, чем возмущаться, что огонь жжется, давайте лучше вместе подумаем, как его можно использовать не обжигаясь? Я попробую написать на эту тему скоро, буду рад вашему мнению. Как всегда, критика без грубости приветствуется.

  • Anonymous
    January 01, 2003
    To Kyryl:

  1. Повышение стоимости... нда. Интересно, а почему бы не ввести "принцип as is" в других областях. Например, покупаете Вы хлеб, на нём этикетка "as is", а внутри... э... ну, в общем лучше Вам об этом не думать. Между прочим, я уверен, в этом случае либо хлеб продавался бы значительно дешевле, либо на его производстве очень быстро становились бы миллионерами.
  2. Откуда брать... ещё один философский вопрос. Откуда же нас всех берут? Аист принесёт, конечно же! Во всяком случае переделать программистов, которых годами заставляли работать "быстро и дёшево" в программистов, способных работать качественно и отвечать за свою работу - врядли получится.
  3. Ага. Даёшь Баланс! В конце концов можно в каждом 50-м магазине продавать хлеб сделанный не по технологии "as is", а качественно, но дороже. Так что, переходим на "as is" в мировом масштабе? Будем считать, что этот принцип уже обкатан на области производства ПО, пора расширять его применение... Не знаю как Вас, а меня такая перспектива как-то не очень радует. Впрочем, мы отвлеклись от темы. Суть топика была в том, что в нашей области есть определённые проблемы. Я утверждаю, что корень этих проблем в отсутствии ответственности. Вы с этим не согласны?

  • Anonymous
    December 08, 2007
    Версионность ПО. У ПО как продукта должна быть только одна версия. Та которая пошла в продажу. И производитель должен относится так, как будто у него не будет возможности выпустить патчи и баг-фикс релизы. Но это будет возможно когда изменится отношение к ПО вообще и производителю в частности. Типа: "Вы слышали - ХХХ выпустил патч к своей программе. Ужас! Это значит программа с ошибками! Я лучше куплю такую же программу у УУУ -  отец у них покупал лет 20 назад программу и до сих пор пользуется! И никаких патчей и версий! Только новые модели для новых компьютеров!" Примерно так ;)

  • Anonymous
    December 08, 2007
    Предварительные условия: дается задача программисту. трудоемкость оценивается в 4 часа. трудоемкость оценивают совместно 3 человека: менеджер + два программиста. т.е. она объективная и не заниженная. проходит 8 часов - задача не сделана. или сделана с багами. Вопрос: должен ли программист задержаться и доделать ее? или нужно таких программистов увольнять (если сроки нарушаются постоянно)?

  • Anonymous
    December 08, 2007
    In defense of freeloading managers everywhere :-) - we do get paid a lot, compared to other professions where overtime is less usual. It is a rare Microsoft developer that takes home less than $100K a year including stock and bonuses, and most mid-career to senior devs make closer to $150-200k. Which compares very favorably with $42k/year for a typical US household income (and even to an average CIO, at $183k, accourding to this: http://www.cio.com/article/30901/THE_STATE_OF_THE_CIO_Salary_Comfortably_in_the_Six_Figures). For myself, I am fairly sure that if there's a choice between working overtime (which I do, a lot) and being paid what average American is paid, I would take the former... :-) -S

  • Anonymous
    December 09, 2007
    Элдар, Когда я писал первый пост, то заранее знал, что виновным сделают менеджера, неправильную постановку задачи и т.д., но только не программиста. Поэтому специально написал, что задачу оценивало несколько человек, и что оценка объективная. Могу добавить, что задачу программисту всегда детализируем: обговариваем структуру БД, проектируем классы/методы. Тем не менее - сроки не соблюдаются - приходится задерживаться, перерабатывать и т.д. Мне кажется ваша отрицательная позиция к переработкам обоснована тем, что вы работаете в большой компании, где от одного человека мало что зависит. Т.е. если кто-то завалит свой участок работ, то проект все равно можно сделать в срок, за счет внутренних резервов компании (например, перекинуть программистов с другого проекта). Поэтому и нет смысла задерживаться... В маленьких компаниях с резервами гораздо хуже - поэтому и приходится ошибки программистов исправлять за счет переработок. Иначе - как платить зарплату людям, если продукт не сделан, денег от клиента нет. >И заметьте, ни в одном из этих случаев нет речи об увольнении. Если это и происходит, то обычно по совсем другим причинам. >Хорошие менеджеры это знают. Расскажите, пожалуйста, какие причины могут быть достаточными и необходимыми для увольнения программиста? Существуют какие-либо KPI для оценки программистов? К хорошим менеджерам себя не отношу, т.к. есть проблемы с исполнением проектов в срок, но пока не вижу путей их решения (кроме как набрать более грамотных программистов, что в условиях нехватки программистов на рынке - затруднительно). .... сейчас перечитал текст и понял, что мы с вами вряд ли поймем друг друга. В майкрософт работают лучшие программисты, поэтому вам не понять проблем маленьких компаний. в которых работают отнюдь не супер-таланты. Кстати еще один вопрос: в майкрософт рабочий день начинается в строго определенное время? Или например нужно быть на работе 8 часов, и не важно во-сколько сотрудник пришел на рабочее место?

  • Anonymous
    December 09, 2007
    The comment has been removed

  • Anonymous
    December 10, 2007
    To Powerman:

  1. Мне думается, что описанная Вами ситуация, приведёт к резкому повышению стоимости ПО, разрабатываемого подобным методом и гарантирующего безошибочность. :) Если нарисовать треугольник с вершинами "быстро"/"дешево"/"качественно", то это будет сползание в угол "качественно" за счёт "быстро" и "дешево".
  2. "Если каждый Программист" - а откуда тогда брать их, "мастер-Программистов"? - им же все равно нужно учиться, совершенствоваться и т.д. Тогда либо нужно вводить разделение "уровней ответственности", когда более часто совершающие ошибки Программисты будут плавно перетекать в компании делающие софт "за который мы почти не отвечаем" (и который стоит дешевле и который все равно будет вытеснять "дорогой и ответственный" софт), либо мириться с тем что избыток ex-Программистов будет присутствовать на рынке труда, возможно криминализируя его и демпингуя (зачем платить сертифицированным Программистам - наймите бригаду мексиканских/молдавских/украинских и они сделают то же самое, но в 5 раз дешевле, и налоги платить не надо) - а варианта "массовые расстрелы" не предусмотрено (товарищу Сталину было намного проще в этом плане) ;)
  3. Существующая сейчас ситуация, имхо, представляет некий баланс для всех сторон: разработчики, разработчико-владельцы :) и пользователи: каждый выбирает ту сторону треугольника дешевле/быстрее/качественнее, которая ему подходит. Без существенных изменений в исходных данных (e.g.: расстреляли всех разработчиков с bugs count>0; запустили в U.S. всех желающих разработчиков; etc.), баланс существенно не сдвинется.
  • Anonymous
    December 11, 2007
    The comment has been removed
  • Anonymous
    December 12, 2007
  1. Индустрия характеризуется не этикой ("что говорит совесть отдельного человека"), а наличием стандартов, норм и правил ("каковы требования индустрии"). Аналогия: уголовный кодекс базируется не на этических нормах, а на интересах государства. Хотя этические нормы и интересы государства могут совпадать.
  2. Предлагаю добавить правило: разработчики ведут разработку (в том числе оформляют документацию) по международным или хотя бы национальным стандартам. Короткий тест: какого цвета обложка сборника стандартов России(США) на разработку ПО?
  3. Предлагаю добавить правило: продукт должен делать то, для чего он выпущен, то что называется "fitness to particular purpose" и что отрицают лицензионные соглашения всех известных мне продуктов (qmail, упомянутый  Powerman'ом, не пользовал).
  4. Предлагаю добавить правило: контроль продукции осуществляет независимая организация (как в сельском хозяйстве или строительстве). Контрольная организация обладает правом "вето" на выпуск продукта.
  5. Предлагаю исключить правило по поводу выпуска к срокам. Если менеджер контролирует риски сам (как он обязан делать), а не отдаёт на откуп паразитам, проект будет готов в срок с требуемым качеством. Как контролировать риски, давно разжёвано, начиная с "Dynamics of software development" и "Rapid application development". Кстати, по трём известным мне примерам, выпускники Гарварда не слишком толковы в управлении разработкой ПО.
  6. По поводу сверхурочных часов. Старый босс говорил: "Если у менеджера программисты сидят по вечерам, значит он не умеет планировать - его надо уволить". Овертайм - это форма героизма, а героизм - это свидетельство плохой организации процесса. Программиста, отработавшего 8 часов, надо гнать от компьютера, иначе завтра он придёт невыспавшимся и запорет ответственный модуль. Никакая оплата, даже трёхкратная, не сделает человека менее утомлённым на следующий день. Кстати, 8-часовой рабочий день - это законодательная норма. Подумайте, почему.
  • Anonymous
    December 15, 2007
    В одной из компаний (Москва) одно время была принята следующая практика. ПМ получает бонус как процент от экономического эффекта проекта. Процент действует симметрично в обе стороны, то если проект не выгодный, ПМ также страдает. Стоит отметить, что соотношения фиксированной части оплаты и этого процента позволял не ставить неудачного руководителя под угрозу выживания. Так вот, сверхурочные программистов всегда оплачивались по двойной ставке... за счет бонуса ПМа. Потом от этой практики отказались, поскольку овертаймы стали редкостью, и накладные расходы на обслуживание этого процесса перестали оправдывать получаемый эффект. Компания при этом весьма прибыльная и ее сотрудники подтверждают, что работают не более 40-45 часов в неделю. Также стоит отметить, что ПМы стали очень внимательно относиться к процессам привлечения персонала, сыграв на озвученном в предыдущих комментариях факте о том, что лучшие стоят дороже в 2 раза, а работают эффективнее как минимум на порядок.