Под катом чек-лист, полезный любому разработчику ПО, но особенно полезный для старших/ведущих инженеров (сеньоров).

Замечание 1: Оригинал на английском находится вот здесь.
Замечание 2: Не забываем про культурные особенности, часть советов может быть не применима или не так актуальна в наших реалиях, но в целом - мне нравится.
Замечание 3: Мои комментарии в последнем столбце, первые столбцы взяты из источника и вольно переведены.



Платформа блогов не умеет такие большие таблички показывать, поэтому вот.

Под катом чек-лист, полезный любому разработчику ПО, но особенно полезный для старших/ведущих инженеров (сеньоров).

Замечание 1: Оригинал на английском находится вот здесь.
Замечание 2: Не забываем про культурные особенности, часть советов может быть не применима или не так актуальна в наших реалиях, но в целом - мне нравится.
Замечание 3: Мои комментарии в последнем столбце, первые столбцы взяты из источника и вольно переведены.



Платформа блогов не умеет такие большие таблички показывать, поэтому вот.

Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...

Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...

Я понимаю, что особенность российского менеджмента в том, чтобы бить пряником, но тут попались на глаза два интересных исследования, одно официальное, другое на уровне байки... Эффекты мне показались интересными, поэтому прошу под кат.
Я уже как-то поднимал вопрос о применении наказаний, но вот в чем загвоздка. Если наказание становится плановым и ожидаемым, то оно может спровоцировать на негативное поведение.
Итак первый эксперимент описан вот здесь. Для тех кто лениться читать много букв по ненашенски, краткая суть. Есть проблема, что родители опаздывают забирать детей из детских дошкольных учреждений. Была выдвинута гипотеза, что если ввести штрафы, то ситуация улучшится. Штраф ввели в размере 20 новых шекелей (эксперимент, если что, был в Израиле), что составляет порядка $5. Нужно понимать, что при постоянных опозданиях сумма может выйти в месяц к $100. Т.е. достаточно существенной. Результат оказался противоположным. Детей стали забирать позже:
Черный график это по садам где был введен штраф, белый - контрольная группа. Как такое может быть? Очень просто. Мы люди животные социальные. И в процессе эволюции был выработан такой замечательный механизм как совесть (социальная чуткость, если хотите). Мы научились ставить себя на место других. И когда из-за нашего опоздания задерживается воспитатель, нас это гнетет. Но достаточно ввести за это материальную ответственность, как совесть выключается и мы начинаем поступать так, как нам удобнее. Самое интересное, кстати, было потом, когда штрафы отменили. Совесть обратно не включилась. Нет, эффект при отказе от штрафов был, но к первоначальному значению опозданий так и не вернулись.
Второй, неверно, не эксперимент, а интересный опыт практикуется в компании Boing. Я по ключевым словам первоисточник не нашел, поэтому на уровне байки. Если кто найдет, буду признателен за ссылку. Здесь тоже пойдет речь про опоздания, но вот только не с детьми и детскими садами, а с опозданиями на работу. Каждый сотрудник компании Boing проходя через проходную до официального начала рабочего дня получает лотерейный билет. По которым проводилась ежемесячная лотерея. Не все билеты были выигрышными, поэтому чем больше у тебя билетов (читай чем чаще ты приходишь на работу вовремя), тем больше шансы выиграть неплохой приз, вроде как разыгрывалась бытовая техника. После внедрения такого новшества количество опозданий сократилось на 70%.
Так что, не всегда наказания позволяют изменить поведение, а вот всякие трюки геймификации действуют на нас, наемных сотрудников, весьма неплохо. Правда у меня есть подозрение, что эффект будет не очень долгосрочным и стимулы придется менять.