На форумах MSDN задали вопрос "Поясните, пожалуйста, с примерами, чем junior и middle отличаются от senior?". Ответ на этот вопрос будет или субъективным, или очень формальным. Многие организации идут по второму пути. Вводят что мидла должен соответствовать критериям А, Б; миддл критериям В, Г; а синьор должен еще и Д и Е. За такими формальными штуками в эти организации. Под катом мое субъективное мнение никого ни к чему не обязывающее.



Junior - разработчик с небольшим опытом на применяемой платформе. С хорошим качеством может решать похожие задачи. Задачи с которыми раньше не сталкивался вызывают существенный перерасход по времени и выполняются с низким качеством (здесь могут быть как откровенные баги, так и архитектурные ошибки). Практически никогда не думает об альтернативных возможностях работы кода.
Middle - разработчик с опытом реальной разработки на платформе от года и выше. С хорошим качеством и в приемлемые сроки решает как повторяющиеся так и новые задачи. Архитектурные вещи, как правило, косячит. При написании кода предусматривает альтернативные сценарии (контроль входных данных, обработка ошибок).
Senoir - разработчик с очень хорошим знанием платформы. Может не только решать задачи, но и видит когда их можно не решать, может предложить альтернативные способы реализации лучше удовлетворяющие функциональным или нефункциональным требованиям. Полностью с приемлемым качеством может разрабатывать архитектуру средних и крупных программных систем. В зависимости от того к чему лежит душа в дальнейшем или все больше занимается архитектурными вещами и переходит в архитекторы, или больше занимается проработкой требований, обучением коллег и переходит в тимлиды.

На форумах MSDN задали вопрос "Поясните, пожалуйста, с примерами, чем junior и middle отличаются от senior?". Ответ на этот вопрос будет или субъективным, или очень формальным. Многие организации идут по второму пути. Вводят что мидла должен соответствовать критериям А, Б; миддл критериям В, Г; а синьор должен еще и Д и Е. За такими формальными штуками в эти организации. Под катом мое субъективное мнение никого ни к чему не обязывающее.



Junior - разработчик с небольшим опытом на применяемой платформе. С хорошим качеством может решать похожие задачи. Задачи с которыми раньше не сталкивался вызывают существенный перерасход по времени и выполняются с низким качеством (здесь могут быть как откровенные баги, так и архитектурные ошибки). Практически никогда не думает об альтернативных возможностях работы кода.
Middle - разработчик с опытом реальной разработки на платформе от года и выше. С хорошим качеством и в приемлемые сроки решает как повторяющиеся так и новые задачи. Архитектурные вещи, как правило, косячит. При написании кода предусматривает альтернативные сценарии (контроль входных данных, обработка ошибок).
Senoir - разработчик с очень хорошим знанием платформы. Может не только решать задачи, но и видит когда их можно не решать, может предложить альтернативные способы реализации лучше удовлетворяющие функциональным или нефункциональным требованиям. Полностью с приемлемым качеством может разрабатывать архитектуру средних и крупных программных систем. В зависимости от того к чему лежит душа в дальнейшем или все больше занимается архитектурными вещами и переходит в архитекторы, или больше занимается проработкой требований, обучением коллег и переходит в тимлиды.

Работа программиста тем и прекрасна, что для автоматизации своей работы он может использовать результаты своей работы. Правда бывает, что мы ленимся этим заниматься. Под катом решение, которое было написано года два назад и которым мы пользуемся до сих пор, для оценки требований при планировании.

К решению были предъявлены следующие требования:
1. Простота
2. До окончания оценки никто не видит оценок остальных участников.
3. Считать среднюю оценку.
Пункт два возник из-за того, что как только первый ставит оценку (мы до этого использовали для совместной оценки Skype), все остальные начинают под нее подстраиваться, особенно если этот первый программист с большим опытом.
Ну а пункт три это к вопросу о том, что в долгое время работающих в одном составе командах, оценки особо не нужны (подробнее писал ранее здесь).
Итак, что собой представляет приложение.
Для простоты оно состоит из вебсервиса (без базы данных и с отсутствующей персистентностью), который отвечает за взаимодействие клиентов и клиентского приложения, которое запускают у себя участвующие в оценке.
Вот так выглядит главное окно (картинки кликабельны):
При входе необходимо указать имя и с какой ролью входит участник. А дальше для ведущего есть возможность указывать номер оцениваемого требования и завершать оценку, для всех есть возможность перейти по ссылке (номер оцениваемого требования) в систему управления задачами и вторая доступная возможность поставить оценку. Ведущий и все участники оценки имеют возможность видеть кто уже оценил (минус - оценки еще нет, плюс - оценку участник уже поставил). Как только все оценили (оценку если что можно и менять в процессе обсуждения), ведущий нажимает кнопку показать результаты оценки:
Показывается кто как оценил и среднее. Если оценки очень сильно разняться, можно еще раз обсудить, но в  большинстве случаев можно сразу брать среднее и ставить его в требование.
Вот такое простенькое приложение нам немного облегчает жизнь каждые две недели.

Это самое ужасное рассуждение: если я не могу всего — значит, я ничего не буду делать.
 -- Лев Николаевич Толстой

Вот здесь, несколько картинок и рассуждений по Chaos Report 2015. Кому интересно, можно пойти и посмотреть в оригинале. Пару картинок которые мне показались интересными, я утащил под кат.

Первая картинка самая говорящая и именно она послужила причиной такого заголовка у этой заметки. Действительно, за последние 5 лет особо заметных изменений нет (картинки кликабельны):
Как была полностью успешна треть проектов, так и остается. Ровно половина проектов завершается со срывом сроков, запланированного объема работ или бюджета. И почти пятая часть от всех проектов так и не доходит до пользователей.
Вдумайтесь, за эти пять лет прошли тысячи конференций, выпущены миллионы книг и все это про то как писать код, управлять требованиями, проектировать архитектуру и в целом управлять проектами. В этот же период на смену четвертому PMBook вышел пятый. А воз и ныне там. Может мы не тем занимаемся?
Еще интересная картинка:
Из всех успешных проектов за 5 лет 62% это маленькие проекты! Т.е. если запускаешь средний или больше проект, шансы уложиться в срок и деньги составляют менее 7%. Одна пятнадцатая. Шансы вообще его хоть как-то выпустить в этом случае составляют 25%. Четверть! Впечатляет.
Ну и последняя картинка. Какие факторы наиболее важны для попадания в треть счастливчиков:
Как видно из картинки успех проекта на 60% состоит из поддержки руководства, эмоциональной зрелости (насколько люди хорошо взаимодействую друг с другом), вовлеченности пользователей и оптимизации процессов (в том числе, разбиением крупных проектов на мелкие).
Самое забавное, это Agile находящийся на 7 позиции. А анекдот здесь в том, что именно Agile говорит что надо взаимодействовать с пользователями, выпускать продукт инкрементально (в виде небольших проектиков закрываемых за две недели и поставляемых пользователю), а уж оптимизация процессов в Agile это один из ключевых моментов. Но ладно пусть будет седьмое место.
Вот так и живем...

Нет такого человека, который был бы достаточно хорош, чтобы управлять другим человеком без его согласия
  -- Авраам Линкольн

В 2002 году у меня появились первые подчиненные. Само-собой, была куча ошибок, не очень удачных решений, но что-то и получалось. Часть на уровне интуиции, часть подсмотрев поведение других руководителей.
Если пользоваться классификацией психотипов предложенной Адизесом, то я "производитель". И видимо этим объясняется, что самым сложным в освоении навыком управления для меня было отдать принятие решений другим людям. Под катом упоминаемая в предыдущей статье модель, позволяющая на основе если-то понять, какой вид лидерства наиболее применим в текущей ситуации.
Как я уже написал выше, делегировать было для меня очень тяжело, ведь мне нравиться делать самому, а еще и психотип бубнит в уголочке, что я один знаю как правильно. И здесь очень важно без перегибов в ту или иную сторону. В каких-то случаях принятие решение должно остаться прерогативой руководителя, в других решения могут и должны приниматься командой или ее членами. Модель Врума-Йеттона как раз про это. Начнем с описания какие варианты поведения предлагает модель. Их всего пять:
Стиль AI. Вы сами решаете проблему или принимаете решение, используя имеющуюся у вас на данный момент информацию.
Стиль АII. Вы получаете необходимую информацию от своих подчиненных, и затем сами решаете проблему. Получая информацию, вы можете сказать или не сказать своим подчиненным, в чем состоит проблема. Роль ваших подчиненных в принятии решений - представление необходимой информации, а не поиск и оценка альтернативных решений.
Стиль CI. Вы излагаете проблему индивидуально тем подчиненным, кого это касается, и выслушиваете их идеи и предложения, но не собираете их вместе в одну группу. Затем вы принимаете решение, которое отражает или не отражает мнение ваших подчиненных.
Стиль СII. Вы излагаете проблему группе ваших подчиненных, и весь коллектив выслушивает все идеи и предложения. Затем вы принимаете решение, которое отражает или не отражает мнение ваших подчиненных.
Стиль GII. Вы излагаете проблему группе ваших подчиненных. Все вместе вы находите и оцениваете альтернативы и пытаетесь достичь согласия касательно выбора альтернативы. Ваша роль фасилитатора. Вы не пытаетесь влиять на группу, чтобы она приняла «ваше» решение, а хотите принять и выполнить любое решение, которое вся группа сочтет наиболее приемлемым.
Как видно, весь спектр, от авторитарного решения в одиночку, до передачи принятия решения группе. Для определения какой из этих стилей поведения применять, служат восемь вопросов:

Есть две одинаково удобные позиции: либо верить во все, либо во всем сомневаться; то и другое избавляет от необходимости думать.
-- Анри Пуанкаре

В фейсбучной группе про ТОС наткнулся на статью "3 способа принятия сложных решений". И что-то как-то зацепило. Под катом размышления на тему как выбирать, и почему то что описано в статье по ссылке опасно.

Начнем с того, с чем я согласен. Во-первых, надо экономить мышление. Исследования показывают, что наш ресурс на принятие решений ограничен. Причем, батарейка этого ресурса общая с силой воли, что тоже хоть как-то но связано с принятием решений, но она еще связана и с памятью. Т.е. неважно думаем мы над чем-то, просто запоминаем что-то это приводит к расходу энергии. Во-вторых, я категорически согласен, с тем, что если есть несколько достаточно удачных решений, то надо не пытаться найти максимально верное решение, самое правильное решение, решение с наименьшими рисками. У меня на эту тему даже вот такая картинка рядом с рабочим местом висит:
И здесь проблема не только в обезьянке Тима Урбана. Мы не можем предсказывать будущее, от слова совсем. Никто и никогда не узнает как работает то или иное решение, к каким последствиям приведет, какие риски реализуются. И здесь действительно, чем раньше мы начнем действовать, тем больше вероятность получить результат, ну или понять, что этот вариант нас к нему не приведет.
Теперь о том, с чем не согласен. Здесь вот какая штука. Если нам не нравиться какая-то наша модель поведения, то да, привычки это 100% выход ее изменить. Про это как-нибудь отдельно, но основная идея в том, что не надо заставлять себя правильно питаться, должна быть привычка правильно питаться. Не надо заставлять себя что-угодно (мыть руки, читать инструкцию перед тем как сломать, заниматься спортом), а должна быть привычка. И это позволяет экономить пусть будет по Максу "мыслетопливо". Но у привычек есть и другая сторона. Как только мы переводим деятельность в бессознательное, т.е. решения принимаем "быстрой" подсистемой мозга, так тут-же качество этих решений ухудшается. То что было хорошо в той ситуации когда привычка вырабатывалась (нами осознанно или внешними обстоятельствами неосознанно), может оказаться не так эффективно, а зачастую и вредно в той ситуации в которой привычка пытается выстрелить.
Еще одним существенным минусом наличия привычек является отсутствие возможности потренировать мозг в принятии простых решений. В книге "Сила воли. Как развить и укрепить" даже одно из упражнений на тренировку силы воли и осознанности, когда мы боремся с привычкой. А тут нам говорят - забей, неосознанное супер.
Что же тогда с этим делать?
Первое и самое главное, это экономить мыслетопливо. Думать над задачей один раз, фиксировать принятые решения в системе учета задач и т.д.
Второе, для ситуаций когда решений больше одного понятно, но что делать с ситуациями с которыми не понятно? А здесь как раз упоминаемые вскользь в статье схемы если-то. И чем на большее количество таких схем будет настроен мозг, тем лучше. Кстати, это хорошая привычка прогонять по таким схемам все непонятно.
Ну и пара примеров на эту тему, а то в статье какой-то мутный.
Классика жанра, разбор входящих:
Имея входящее и подойдя к времени разбора, все что накопилось прогоняем по этой схеме если-то и удаляем. Применимо ко всему: просьбам, письмам, идеям. Есть отдельно тонкости что помещать во входящие, а что сразу прогонять по этой схеме, но лучше (если вы только начинаете со всем этим разбираться) все сначала помещать во входящие, а то может тупо захлестнуть волной из входящих которые типа на две минуты и быстренько сделаю.
Второй пример был для меня в новинку, поэтом про него поподробнее отдельной статьей. А вот картинка для затравки:

Видео с конференции Community DevCamp проходившей в декабре прошлого года.

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