По работе делал достаточно большой список ПО в некоторой области (это не важно). Важно то, что рассматривал ПО отечественное и для сравнения - ПО западное (строго говоря - не отечественное, не ограничиваясь условным "западом", то есть - ПО иностранное). Так вот, что меня поразило: "наши" обычно не размещают никаких демок, а функции пишут так, что вообще непонятно, почему эта прекрасная система, которая умеет всё еще не установлена везде, и зачем нужны в принципе другие системы... На иностранных сайтах функции пишутся более адресно и более полно, и как правило есть демка, ну хотя бы видеоролики. Посмотришь их - и более менее понятно, хотя бы на самом верхнем уровне,"что это". 

А "наши" отличаются тем, что всё по запросу. Не страшно, но времени продраться через вот это всё уходит много. Хотя желание разобраться падает.

Отличное видео выступления Олега Макарова на конференции Sales & Marketing 360

Сразу же предупреждаю: видео длинное, почти час, но оно того стоит. Чем оно хорошо? Олег просто и доходчиво объясняет что такое мотивация. Что такое лояльность. За что "покупается" мотивация и как получить лояльность, а также - чем эти понятия отличаются, и какие из этого следуют выводы.

Я посмотрел несколько раз, и кое-что даже законспектировал. :) Там вроде бы очень простые идеи. Но при этом - каждый раз ощущение, что "блин, ну как я это упустил, а?".

Ссылка на Ютуб: https://www.youtube.com/watch?v=MOIIcW-Lsxk

• Первая статья: Елена Тюрина. Как разработать KPI для удаленных сотрудников
• Вторая статья: Олег Кулагин. Лукавые цифры: почему для расчета KPI мало знать «план» и «факт»
• Третья статья: Олег Кулагин. Как рассчитать премию сотрудника на основе KPI

Три предельно практические статьи об одном и том же: как разработать систему мотивации на основе показателей (KPI). А проблема по большому счету, совсем не нова. Рано или позно - но "как мотивировать рублем" встает перед каждой компанией. Ну, или перед каждой...

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

И да, в сознательно не включил в подборку ничего про нематериальную мотивацию - не стоит мешать всё в одну кучу.

На Хабре очережная интересная статья: "Что нужно учесть при проектировании системы, чтобы не было мучительно больно?". Статья о том, как много боли можно получить впоследствии, изначально - неверно спроектировав приложение.

Вернее, как "неверно спроектировав". Понятное дело, что когда гипотетическое веб-приложение типа "сайт с некоторыми функциями" делается "для себя" / "для 100 - 1000 пользоваталей", то по большому счету - не очень важно, "синхрон-асинхрон", "прямые права" (не через роли) и т.д. Когда пользователей становится 100 000 - 1 000 000 и выше, эти проблемы начинают "выстреливать", причем - в самый неожиданный момент. Да, кстати, это не только для веба - это в принципе, для многопользовательских приложений. У всех свои "пороги срабатываения проблемы", но то, что проблема "выстрелит" на больших объемах, если её оставить - 100%. Безальтернативно.

Понятное дело, что поначалу никто не планирует "выход на объем", но вот что точно нужно делать в самом начале - как следует проработать архитектуру приложения, с тем, чтобы впоследствии было проще "расшивать" узкие места. Автор статьи, кстати, делает совершенно аналогичные выводы. Не касаясь явно, правда, еще одного момента - а именно объема данных. Косвенно о них говорится в разделе "Масштабирование", но явно - нет. А это, вообще говоря, может быть той еще головной болью. Когда, например, хранилище данных достигает 10000 Тб, и нужно обеспечить быстрый доступ ... или, как вариант, необходимо хранить таблицу в пару-тройку десятков миллионов строк... еще раз скажу, что редко когда на старте думаешь о том, что так будет. Но бывает, и еще как! В одном случае - логирование действий пользователей с ростом их числа съедает всё место, в другом - начинают в систему "заводить" не предназначенный для этого "тяжелый" контент (видео и т.д.). И получается на выходе - тормоза, отказы, 503я ошибка или просто "висим намертво".

Так что мораль: если вы только начали проектировать приложение - думайте о росте. Если приложение уже есть, но в нем еще нет ни пользователей, ни данных - думайте о росте. Потому что если не думать, то "рост" заставит вспомнить о нем сам. И будет существенно больнее.

Классная статья на сайте Executive.ru: http://www.e-xecutive.ru/management/practices/1986548-pochemu-verhi-i-nizy-v-kompaniyah-ne-ponimaut-drug-druga

Статья, что называется - "в точку". Она о том, что в числе прочего - интересы работника и работодателя могут не совпадать. Запросто могут не совпадать. (И вообще говоря, это нормально).  Кроме того - она о том, что сделать с этим.

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

Прочитал "7 препятствий для внедрения гибких методологий в больших организациях".

Что сказать. Согласен, если не с каждой буквой, то со многим. Я видел как внедряют SCRUM в больших и очень больших организациях. И особенно "доставляет" переходный период, когда творится адский треш из "старой" и "новой" методологии, при этом - необходимо выдержать сроки, при этом - кроме сроков еще надо внедриться и отчитаться...

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

• зачастую руководство выстраивает псевдо-SCRUM, чтобы и SCRUM внедрить, и "нити" не потерять
• живут по принципу "ну ок, у вас SCRUM, а нам - надо сделать вот это, прямо здесь и сейчас, и не важно, над чем сейчас работает команда" (в классике - задание должно приходить на скрам-мастера, команда может пересмотреть приориеты... но чтобы так вот в жизни делали?)
• считают внедрение SCRUM инородным элементом. "Вы там внедряйте, а мы потихоньку, в прежнем режиме... если надо - отчитаемся". То есть низкая мотивация к самосоверщшенствованию команды (а это - основа SCRUM).
• Ну и - целеполагание. Цели зачастую ставят "по водопаду", отчетов требуют "по водопаду", а работы - по SCRUM.

Печально, но факт.

Аркадий Моренис (https://www.facebook.com/amoreynis):

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

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

Без горизонтальной черты человек превращается в "кол", он вбивается все глубже в землю, зная все больше и больше о все меньшем и меньшем.

Без вертикальной черты основной специализации он становится "зеленым и плоским" – человеком, который знает все меньше и меньше о все большем и большем, но которого издалека и не разглядишь (smiley)

Как оказалось, этот термин широко известен в узких кругах. Но что лично меня прикалывает – в слове Technology первая буква тоже "Т". И это как бы намекает, что правильный технологический специалист должен быть "Т-человеком" по определению.