Отличная, на мой взгляд, статья "Почему менеджеры уклоняются от решений как дети": http://www.e-xecutive.ru/career/lichnaya-effektivnost/1987164-pochemu-menedzhery-uklonyautsya-ot-reshenii-kak-deti

Продолжаю разгребать загашники интересного, прочитанного мной.

Вот, например, на Хабре была интересная статья "Хабр. Увольнение – это маленькая смерть. Как сохранить ценного специалиста решившего уволиться?" (автор - вице-президент Parallels Николай Добровольский). Случай, когда согласен буквально во всём. Почему? Да потому что видел массу случаев, когда талантливые, целеустремленные люди уходили. Да, незаменимых не бывает. Но цена этого - потери в деньгах (старый ценный сотрудник занет много больше, чем новый сотрудник), потери во времени (от трех месяцев до полугода проходит прежде чем новичок начинает хотя бы разбираться... не говоря уже о глубоком понимании и погружении в процессы). Менеджеры очень часто забывают (или предпочитают не видеть), что замена специалиста - это тоже процесс. И еще один аспект. Я, также как и автор - имею привычку привязываться к людям. И для меня сложно как пережить уход человека, с которым работал (наверное, поэтому я со мнигими продолжаю общаться), так и перейти куда-то самому (хотя периодически приходится это делать).

В общем, статья.

Попалась очень хорошая, дельная статья. Соверешнно банальная идея: мир имеет несколько срезов, и мы, примеяя оценки в матрице soft-hard skills видим один срез - и упорно не замечаем остальных. Мы оцениваем одно, и не видим другое. Автор говорит, что зачастую мы не видим такую любопытную систему координат: самоконтроль - продуктивность - мудрость - восприятие - влияниев. Да, это совсем не sodt skills - но, согласитесь, качества не менее важные. В общем, рекомендую.

Линк

Хорошая статья на Хабре: как написать гармотный SLA. https://habrahabr.ru/post/336868/

Чем хороша статья? Приведу только основные тезисы:

• SLA должно иметь границы
• SLA должно быть связано с сервисом
• Суть SLA - контроль процесса
• SLA должен содержать метрики (а метрики должны быть конкретные, измеримые и т.д.)
• SLA должен быть зависим только от работы Исполнителя (тут дополнение от меня: SLA можно связать в цепочку при помощи OLA и настроенной системы обмена информацией - это важно в сложных системах).

И примеры. И типичные ошибки. В оющем и целом - очень грамотная статья. Очень.

Юольшая и хорошая статья на Хабре о том, почему не взлетел и в итоге умер проект Ubuntu Touch. Это была прекрасная попытка завести Linux на мобильных устройствах, тпа планшетов. Я вот - сознаюсь - все думал купить себе Intel Atom планшет и "запилить" туда Linux... Или дождаться стабильного Ubuntu Touch и купить устройство уже с предустановкой. Первый путь пока держу в голове - вот фиг знает, надо время ... второй отпал сам собой.

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

Ссылка.

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

На e-xecutive.ru попалась очень дельная статья "Почему разочаровывают попытки создать "бирюзовую организацию".

Там вообще-то не про "бирюзу", а про конкретные проблемы - про то, что надо сделать, чтобы улучшиться, вырасти "над собой". Очень точно и концентрированно.

Ссылка