Жесткий менеджмент — Дэн Кеннеди

жесткий менеджмент

Основные идеи:

  1. Введение «Программы» для новых сотрудников. С самого начала предоставляйте новоприбывшим сотрудникам четкую программу обучения и адаптации. В противном случае, более опытные сотрудники могут дать новичкам свои собственные, возможно, нежелательные советы. Люди не умеют читать мысли, поэтому важно заранее объяснять, чего вы от них ожидаете.
  2. Оптимизация зарплатного фонда. Установите зарплату на уровне, близком к минимальному, чтобы иметь возможность предлагать более высокую оплату тем сотрудникам, которые действительно выделяются. Создайте такие условия работы, которые будут привлекательными для сотрудников и позволят вам предъявлять высокие требования. Пусть люди ценят своё место и боятся его потерять.
  3. Разумное управление персоналом. Не бойтесь расставаться с сотрудниками, которые не справляются с задачами. Подходите к найму медленно и осознанно, но расставайтесь с неэффективными сотрудниками быстро. Важно осознавать, что рано или поздно каждый может перестать соответствовать требованиям, и в таких случаях лучшее решение — увольнение.
  4. Приоритет маркетинга. Маркетинг должен быть на первом месте, и все остальные отделы должны поддерживать его стратегию и задачи. Всё, что делает ваша организация, должно соответствовать целям маркетинга.
  5. Проблемы корпоративной культуры. Воровство и коррупция могут встречаться в любой корпоративной культуре, будь то американская или российская. 
  6. Теория разбитых окон. В книге приведён пример с конюшней, где регулярно красили забор площадки для выгула лошадей в ярко-белый цвет. Этот белоснежный забор привлекал внимание клиентов и стал элементом маркетинга, который успешно способствовал продажам.
  7. Необходимость строгого контроля. Для эффективного управления необходимо тщательно следить за работой сотрудников. Используйте все доступные средства — камеры наблюдения, прослушивание, мониторинг интернет-активности подчиненных — чтобы быть в курсе всего, что происходит.
  8. Будьте решительными. Не стоит оправдываться и думать, что ваш коллектив на что-то не способен. Действуйте уверенно и решительно, несмотря на возможные сомнения сотрудников.
  9. Скорость как ключ к успеху. В бизнесе важна оперативность. Не бойтесь запускать проекты, даже если они ещё не до конца доработаны — со временем можно устранить недостатки. 
  10. Публичные показатели эффективности. Разработайте систему ключевых показателей и сделайте её доступной для всех сотрудников. Это создаст здоровую конкуренцию, где худшие уйдут сами, а лучшие будут рады своим успехам. 
  11. Остерегайтесь «синдрома серого человека». Серость и отсутствие инициативы могут погубить бизнес, но важно помнить, что работа — это не развлечение, а серьёзная деятельность.
  12. Неожиданные выводы о продажах. Увеличение комиссионных не всегда стимулирует продавцов работать лучше. Часто это приводит к тому, что сотрудники достигают комфортного уровня дохода и затем снижают свою активность.
  13. Постоянное обучение. Регулярное чтение книг и их обсуждение в коллективе — важная часть саморазвития. 
  14. Создание и поддержание связей. Важно активно налаживать социальные контакты и связи, поскольку они играют ключевую роль в бизнесе.
  15. Прибыль как главная цель. Основной целью бизнеса является получение прибыли. 
  16. Будущее рынка и экономические кризисы. В книге также рассматривается будущее рынка и возможные финансовые кризисы. Кеннеди предполагает, что рынок разделится на два направления: одно — тотальная автоматизация и удешевление через интернет и использование роботов, другое — премиальный сервис и высокие цены для богатых клиентов.

Обзор Книги — Не заставляйте меня думать — Стива Круга

Стив Круг — Не заставляйте меня думать

Самое актуальное издание книги — третье. Опубликовано автором в 2013м году. Почти десять лет прошло.

Считается, что книгу нужно прочитать одной из первых специалистам по Пользовательскому опыту на веб сайтах (UX-специалисты). Материал в книге подается просто и понятно. Специалистов по пользовательскому опыту на веб-сайтах пока еще мало и не каждая компания имеет такого. Поэтому стоит ознакомиться с книгой и разработчикам. Тем более что объем книги небольшой.

Некоторые вещи из книги кажутся очевидными, но ценность в акценте на них как на важных. Основной посыл книги заложен в названии — «Не заставляйте пользователя думать». Идея кажется простой, но реализовать ее сложнее.

Мысли, которые почерпнул для себя из книги Стива Круга:

  • Со временем эволюции веба, у пользователей уже сложились представления о том, как должен выглядеть сайт. Где находится логотип, где меню, где разделы, где основная информация. Лучше размещать эти разделы так и там где пользователь привык их видеть. Не стоит удивлять пользователя и заставлять его искать привычные вещи.
  • Привычные названия для действий — это хорошо (кнопка «Регистрация»). Не привычные, остроумные, вычурные — плохо (вместо «Войти» — кнопка «Вперед за впечатлениями!»), так как заставляет пользователя задуматься и потерять время.
  • Основная навигация сайта (лого, слоган, меню, футер) и сервисные функции (войти, зарегистрироваться, поиск) должны быть на каждой странице и выглядит одинаково
  • Пользователи проводят на нашем сайте гораздо меньше времени, чем мы думаем. Редко они читают заготовленный текст полностью. Только если это не статья по интересующей его теме или «рецепт ребрышек в духовке». Пользователи хватают информацию кусочками: пару слов из целого предложения; первое предложение из абзаца.
  • Текст необходимо форматировать так, чтобы его было удобно просматривать («просматривать» отличается от «читать»). Иерархия заголовков. Короткие абзацы. Маркирование списки. Выделенные ключевые слова или понятия
  • Эффективная визуальная иерархия. Чем важнее элемент, тем он должен быть заметнее. Визуально связываем логически-связаные элементы. Часть чего-то большего оформляем вложенностью в это «большее»
  • Логические области (лого, меню, контент, баннеры, навигация, футер) должны быть четко разграничены, чтобы облегчить пользователю ориентацию на сайте
  • Кликабельные области (кнопки, ссылки, табы) должны быть выделены, привычным образом. Чтобы не было сомнения, что это кнопка или ссылка
  • Логотип сайта находится слева сверху. Рядом — слоган, которые четко объясняет куда мы попали и чего ожидать от сайта («Лучшие свежие торты Санкт-Петербурга»)
  • Хлебные крошки на сайте — это хороший тон. Если иерархия страниц больше 2х уровней.
  • Обязательно включаем поиск по сайту. Некоторые пользователи сразу же приступают к поиску, а не навигированию через меню
  • Пункты навигационного меню должны быть лаконичными, но понятными. Включать в свои разделы точно идентифицируемые области, а не пересекающиеся. Чтобы у пользователя не возникало вопроса «Бензопила» находится в разделе «Домашнее хозяйство» или «Для дачи»
  • На главной странице сделать акцент на то, от куда начать пользователю. Это или Регистрация или Покупка или Чтение лучших статей.
  • В сражении за место на главной странице между отделами (маркетинг, сео, продакт, заказчик, директор, ux-дизайнер и другие) необходимо, чтобы ответы на 4 основных вопроса легко находились. 
  1. Что это за сайт?
  2. Что я могу здесь делать?
  3. Почему я должен остаться здесь, а не где-либо еще?
  4. Какие материалы здесь есть?
  • Главная страница все еще важна. Даже если на ваш сайт попадают из поисковика и не на главную.
  • Юзабилити-тестирование очень полезная технология. Можно получить много идей для улучшения веб-сайта, пригласив сторонних людей попробовать с ним работать

Впечатления о книге — Первый среди равных — Майстер, Маккенна

Первый среди равных

Почему стоит прочитать книгу:

  • Книга помогает сформироваться лидеру группы. В мире программирования, лидер — это технический директор, тим-лид, сеньор в команде разработки.
  • Отвечает на множество вопросов по работе лидеров групп
  • Приведены примеры реальных ситуаций-вызовов. Какие решения предлагали лидеры известных компаний

Недостатки книги для меня, как айтишника:

  • Многие примеры ориентированы на “продажников” или менеджеров компаний, управляющих ими
  • Текст рассчитан больше на американские или западно-европейские реалии

Но это не мешает понять главное в отношении менеджеров и сотрудников

Моменты, которые я выделил бы для себя:

  • Программисты считают себя интеллектуальной элитой и не признают авторитетов. К ним нужен особый подход
  • Формальная должность менеджера работает плохо. Чтобы лидерская позиция работала эффективно, надо чтобы команда признала лидера и неформально. В этой книге много советов в этой области
  • Вам должны доверять. В вас должны видеть советника. А чтобы это произошло, нужно помогать своим подопечным. Делать это корректно и терпеливо. При этом не навязывать свою помощь. Помощь будет удачной, только если она своевременна.
  • Подчиненные должны нравиться лидеру группы. Если это не получается сразу, необходимо найти черты или способности, которые помогут. Это важный критерий при наборе на работу новых людей
  • Интересоваться жизнью коллег и делиться своей. Строить длительные доверительные отношения. Общаться и за пределами работы
  • Помогать людям понять свои перспективы и мечты, двигаться к ним
  • При этом быть “рядом” в коменты личных или профессиональных кризисов
  • Сотрудники могут допускать ошибки. Они не должны испытывать затруднения, когда рассказывают о своих упущениях. Это достигается созданием безопасной атмосферы в группе
  • Действовать в интересах не только компании, но и своих сотрудников
  • Нововведения в группу намного лучше интегрируются если к ним приходят совместно группой
  • Одобрение — один из самых эффективных форм поощрения. Оно должно быть своевременным, искренним

Наставничество можно описать моделью:

  • Спросите как дела
  • Убедитесь, что человек готов принять наставничество
  • Задайте вопросы и предложите свою поддержку
  • Поделитесь нужной информацией
  • Активно слушайте
  • Помогите найти возможные направления действия
  • Договоритесь о следующем шаге

Модель Помощи отстающим коллегам:

  • Организуем встречу для обсуждения проблем с производительностью
  • Убеждаем сотрудника, чтобы в него верите и хотите оказать поддержку
  • Добиваемся того, что проблема существует и обсуждаем причины
  • Находим идеи для улучшения
  • Договариваемся о конкретных действиях для решения проблемы
  • Устанавливаем конкретную дату для обсуждения того, как идет исправление 

Модель противодействия Проблемному поведению:

  • Организовываем встречу
  • Описываем конкретные ситуации, иллюстрирующие проблемное поведение
  • Объясняем, почему такое поведение беспокоит вас, и выражаем желание изменить его
  • Выслушиваем объяснение коллеги по поводу причин происходящего
  • Помогаем увидеть, как изменение поведения поможет карьере сотрудника
  • Спрашиваем, какие у него есть идеи по поводу решения проблемы
  • Предлагаем свою поддержку и помощь
  • Договариваемся о плане действий и назначен дату для обсуждения хода дел

Впечатление о книге Пиши, сокращай — Максима Ильяхова

Книга Пиши, сокращай Максима Ильяхова и Людмилы Сарычевой

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

Книгу можно найти только в печатном формате. В электроном виде книгу не выпускали намерено. Меня это очень удивило.

В нескольких моих статьях об полезных книгах упоминается, что навык правильно писать — важен для программиста (здесь я добавлю ссылки на эти статьи).

Все это и побудило меня в прочтению и конспектированию основных идей книги:

  • Первая мысль в книге, которая поменяла мой подход в написании текстов: заумные формулировки и красивые обороты не красят текст, а скорее, наоборот, мешают его пониманию. Смысл важнее слов. Лучше писать проще
  • Самый важное в тексте — это создать пользу для того, кто его читает. Противоположность этому — красивые обороты, маскирующие мотивы писателя. Необходимо быть честным и полезным читателю
  • Сделать сообщения понятными поможет сокращение текста. В книге можно найти много рекомендаций, как это сделать. Все они структурированы и подробно поясняются. Что-то стоит убрать, что заменить, что оставить
  • Примеры и короткие истории отлично подойдут для донесения своих мыслей или пояснений
  • С критикой нужно быть тактичным. Критиковать работу можно, человека — нельзя
  • Сложно воспринимаются предложения, в которых заложено несколько мыслей. Такие предложения длинные. В них много знаков препинания. Лучше, если в одном предложении будет содержаться одна мысль.
  • Чтобы исправить текст — необходимо читать его в слух. Так мы выявим как его упростить, улучшить.
  • Абзацы в нашем тексте создают структуру. Структура облегчает понимание.
  • В первое предложение абзаца важно вложить побольше смысла.
  • Как и с предложением, в один абзац вкладываем одну мысль. Разбиваем ее на предложения.
  • Если в тексте много абзацев — необходимо его структурировать. Модуль — это заголовок с несколькими абзацами, которые являются мини-статьей. Что подразумевает в структуре модуля: введение, основную часть и заключение.
  • Чтобы привлечь внимание к статье — она должна быть полезной. Громкие заголовки с пустой статьей навредят читателю. Тем самым, навредят и автору.
  • Все абстрактное имеет мало пользы. Необходимо заменить конкретным.
  • Последняя глава в книге подробно описывает как рекламировать себя. Даже если вы — компания или корпорация.

Главный вопрос, который следует задать себе перед написанием текста — это “Чем вы полезны читающему?”. И ответ на него: честный и конкретный

Впечатления о книге — Чистый Agile — Роберта Мартина

Чистый Agile — Роберт Мартин

Сразу бы хотелось отметить, что книга не рассчитана на людей, которые с нуля (для таких ребят, советую начать с другой книги, представленной в моей статье) хотят разобраться в гибких методологиях, скорее, она (книга) для тех, кто уже успел опробовать какие то методологии и проявляет интерес к этой области. А еще лучше подойдет тем, кто сомневается, правильно ли организованы Agile процессы в команде, так как автор отмечает, что многие организации не понимают или внедряют методы не верно (что может только усугубить проблемы процессов).

Книга написана человеком, который стоял у истоков создания манифеста гибких методологий. 

Все началось со знаковой встречи семнадцати профессионалов разработки программного обеспечения в феврале 2001, чтобы поделиться своими мыслями по поводу эффективности разработки и, в итоге, сформировать Манифест Agile. И за два десятка лет понимание этих принципов претерпело изменения, по мнению автора, далеко не все положительные.

Мысли автора описаны в неформально-разговорном стиле, поэтому некоторые выражения могут показаться не совсем корректными. 

Книга не большая по объему, так как Agile — небольшая идея, предназначенная для решения небольших задач, поставленных небольшими командами программистов, которые выполняют небольшую работу. (Agile не рассчитан на решение крупных задач больших команд программистов, которые занимаются крупными проектами). Здесь представлены основные принципы Agile. И производные от Agile — это уже не сам Agile. Это дополненный Agile со своими опциями.

Вся суть Agile в четырех предложениях Манифеста:

  • Люди и взаимодействия важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану

Автор отмечает интересный факт, что некоторые думают, что Agile способствует скорости выполнения проекта. Это не так. Agile никогда не ставил своей целью выполнить и сдать проект поскорее. Agile помогает вовремя понять то, где и насколько мы облажались. Другими словами, главная цель Agile — защита от самообмана, мы применяем Agile, точны избавиться от ложных надежд, которые в итоге приведут проект к краху.

По мнению Роберта Мартина наиболее подходящий метод Agile — метод экстремального программирования. Из всех методологий Agile это наиболее определенная, исчерпывающая и наименее запутанная методология. В книге этой методологии уделяется, непосредственно, много страниц. Некоторые другие важные методы: метафора, 40-часовая рабочая неделя, коллективное владение и непрерывная интеграция.

Один из наиболее важных методов экстремального программирования — разработка через тестирование. Ее можно описать тремя простыми правилами:

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

Еще один важный метод экстремального программирования — парное программирование. Многие отрицательно воспринимают мысль о том, что два (или более) человека могут плодотворно работать над одной и той же задачей. Однако, работа в паре не обязательна. Никого не стоит принуждать. А еще, работа в паре не обязательно постоянна. Существует много веских причин работать в одиночестве. Право выбора сколько времени работать в паре принадлежит членам команды, самим программистам.

В финале, хотелось бы отметить мысли автора по поводу нового Манифеста Agile, который дополняет оригинальный манифест и расширяет его с точки гения подхода Высшего мастерства разработки.

Являясь устремленными к совершенству мастерами разработки ПО, мы повышаем уровень профессиональной разработки ПО, делая это сами и помогая другим осваивать наше ремесло. 

Занимаясь этой деятельностью, мы прежде всего научились ценить:

  • Не только работающий продукт, но также и искусно разработанный продукт.
  • Не только готовность к изменениям, но также и постоянное увеличение ценности.
  • Не только людей и взаимодействие, но также и содружество профессионалов.
  • Не только сотрудничество с заказчиком, но также и плодотворное партнерство. 

Впечатления о книге — Постигая Agile — Дженнифер Грин

Книга Постигая Agile — Дженнифер Грин

Цель книги: познакомить читателя с методами Agile, а так же ценностями и принципами, проповедующими гибкие подходы к разработке программного обеспечения

Лично мне, книга интересна тем, что на ее страницах раскрываются тайны таких модных понятий как Agile, Scrum, XP, Lean, Kanban как обособленно, так и в сравнении, а, точнее, в гармоничных комбинациях. Другими словами эти методологии и философии дополняют друг друга или лучше раскрывают…

Основные понятия, которые для себя отметил описываются ниже.

Agile

Именно изменение образа мыслей превращает группу сотрудников, добавляющую в свою работу несколько agile-методов, в настоящую команду, которая действительно улучшает способ создания ПО

Манифест гибкой разработки программного обеспечения:

Люди и взаимодействия важнее процессов и инструментов
Работающий программный продукт важнее исчерпывающей документации
Сотрудничество с заказчиками важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану 

12 принципов гибкой разработки программного обеспечения 

  1. Наш наивысший приоритет — это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.

Agile-команды удовлетворяют своих клиентов, получая обратную связь на ранних этапах проекта, и непрерывно поставляют программное обеспечение, чтобы сохранить эту связь актуальной

  1. Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта.

Agile-команды одобряют изменения, рассматривая их как положительные и полезные события для проекта

  1. Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае — каждые несколько месяцев. Чем чаще, тем лучше.

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

  1. Наиболее эффективный и действенный способ передачи информации — это встреча членов команды разработки ПО.

Наиболее эффективное общение между членами agile-команды происходит тогда, когда они сосредоточены на разговоре лицом к лицу и опираются на минимальное количество документации, необходимой для реализации проекта

  1. Представители бизнеса и команда разработки должны работать над проектом вместе.

Для достижения наибольшей ценности программного продукта разработчики ежедневно общаются с бизнес-пользователями

  1. Проекты строятся вокруг мотивированных людей. Создайте для них подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работ

Каждый член agile-команды чувствует свою ответственность за проект и отвечает за успех

  1. Рабочее программное обеспечение — это главная мера прогресса проекта.

Наиболее эффективный способ коммуникации в ходе реализации проекта — поставка рабочего программного обеспечения и передача его в руки пользователя

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

Наиболее продуктивно команды работают в устойчивом темпе, без ненужного героизма и сверхурочных

  1. Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.

Хорошо разработанное и реализованное программное обеспечение намного быстрее поставляется клиенту, потому что в него проще вносить изменения

  1. Простота — это искусство не делать лишней работы.

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

  1. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.

Самоорганизующиеся команды разделяют ответственность за все аспекты проекта, начиная с замысла создания продукта и заканчивая его реализацией

  1. Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий

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

Scrum 

Правила Scrum 

— В scrum-проекте существует три основные роли: владелец продукта, scrum-мастер и член команды.

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

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

— Ежедневно все члены команды участвуют в короткой встрече (Daily Scrum — ежедневный scrum-митинг), чтобы рассказать друг другу о достижениях и обсудить то, что препятствует дальнейшей работе. Каждый человек отвечает на три вопроса: что я сделал с момента последнего ежедневного совещания? Что буду делать вплоть до следующего ежедневного совещания? Какие препятствия есть на моем пути?

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

Чтобы работать по Scrum, команда должна глубоко и на интуитивном уровне понимать коллективную ответственность и самоорганизацию 

Каждый разработчик должен чувствовать себя комфортно, отвечая за работу, под которой он подписался. А поскольку команда исповедует принцип «это наше общее дело», комфортно должен чувствовать себя каждый ее участник 

Пользовательская история эффективна, поскольку делает очевидными три важные особенности:
— Кто наш пользователь: «постоянный посетитель сайта, имеющий длинный список друзей».
— Что хочет сделать пользователь: «номинировать видео одного из своих друзей на достижение».
— Почему пользователь хочет это сделать: «чтобы все наши общие друзья смогли за него проголосовать».    

Экстремальное программирование 

Две основные практики XP — разработка через тестирование и парное программирование    

Lean (бережливое мышление)

Lean — это мышление, а не методология

Команды при помощи бережливого мышления ведут работу по ликвидации потерь, находя любые виды деятельности, которые напрямую не способствуют построению ценных продуктов, и устраняя их

Любая деятельность, которая явно не добавляет ценности проекту, считается потерями. Lean-команды стремятся увидеть их и исключить из проектов, насколько это возможно.    

Канбан 

Канбан — это метод улучшения процессов, используемых гибкими командами 

Канбан отличается от гибких методологий, таких как Scrum и ХР.

Scrum преимущественно ориентирован на управление проектами: объем работы, который должен быть проделан, чтобы эта работа была выполнена, и результат, необходимый пользователям и стейкхолдерам.

ХР ориентирована на разработку программного обеспечения, ее ценности и практики строятся вокруг создания благоприятных условий для развития и формирования привычек, помогающих разработчику писать простой и легко изменяемый код.

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

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

Затем принимайтесь за основные практики:
— визуализацию;
— ограничение числа задач в работе (WIP);
— управление потоком;
— сделайте правила явными;
— введите петли обратной связи;
— развивайтесь совместно и экспериментируйте (используя моделирование или научный подход).

Типичная канбан-доска показывает крупные рабочие элементы, а не отдельные задачи

Впечатление о книге — Грокаем алгоритмы — Адитьи Бхаргавы

Книга Грокаем алгоритмы Адитьи Бхаргавы

Сразу хочу поделиться мыслями:

  1. это книга рассчитана больше на неискушенных людей, у которых почти нету или мало опыта в программировании и алгоритмах (таких как сортировка, поиск оптимальных путей)
  2. тем не менее, она здорово расширяет кругозор в подобных алгоритмах и некоторых процессах, на которых построены алгоритмы известных технологий, таких как поиск в интернете или рекомендательные системы
  3. так же, издание дает пищу для размышления по поводу современных алгоритмов, машинного обучения и советует изучать определенные технологии для дальнейшего развития

Ниже приведены, освещенные в этом труде, понятия, алгоритмы и технологии

  • Бинарный поиск (в том числе в сравнении с обычным поиском перебором) и массивы. Хотя массив поиска должен быть отсортированным чтобы им пользоваться
  • О-большое — порядок времени работы алгоритма. Важное понятие для оценки эффективности (скорости работы) алгоритмов или сравнения разных алгоритмов
  • Задача о коммивояжере (как пример задачи, которую очень тяжело выполнить точно)
  • Связанные списки, как альтернативный массивам тип данных
  • Сортировка выбором
  • Рекурсия и стек (стек вызовов)
  • Быстрая сортировка (используется понятие алгоритма «Разделяй и властвуй» и рекурсия)
  • Хеши, Хеш-таблицы, Хеш-функции
  • Графы, Поиск в ширину для описка кратчайшего пути по графу (когда весов у ребер нету)
  • Алгоритм Дейкстры для поиска наиболее выгодного (быстрого) пути по графу (когда весы у ребер появляются)
  • Жадные алгоритмы, как быстрые, но приближенного решения сверх-сложных задач (NP-полных)
  • Множества
  • Динамическое программирование, как метод решения сложных задач с помощью разбиения на более простые
  • Шутливый Алгоритм Фейнмана (1 — сформулировать задачу, 2 — хорошенько подумать, 3 — записать решение)
  • Алгоритм k-ближайших соседей, как распостраненный метод решения многих задач классификации (распределение по категориям) и регрессии (прогнозирование ответа)
  • Извлечение признаков
  • Машинное обучение на примерах OCR, спам-фильтра, прогноза биржевых торгов

В последней главе книги вскользь (тезисно) касаются следующих тем

  • Возвращаемся к деревьям
  • Инвертированные индексы
  • Преобразование Фурье
  • Параллельные алгоритмы
  • MapRecude и распределенные алгоритмы
  • Фильтры Блума и HyperLogLog
  • Алгоритмы SHA и сравнение файлов
  • Алгоритм Диффи-Хеллмана
  • Линейное программирование

Вывод: книгу следует прочитать на начальном этапе ознакомления с современными алгоритмами или же для расширения кругозора

Впечатления о книге — Искусство объяснять — Ли Лефевер

Книга Искусство объяснять Ли Лефевера

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

Чем то, концепция произведения напоминает таковую из книги «В работу с головой«, где рассматривается углубленная работа, на первый взгляд, элементарное понятие.

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

Цель книги — помочь читающему переосмыслить свою манеру объяснять и научиться упаковывать идеи в объяснения, которые приносят реальную пользу.

Далее, опишу концепции из книги, которые заставили меня задуматься и отметить их для себя:

  • Объяснения требуют умения поставить себя на место собеседника. Это перекликается с умением слушать из очень полезной книги — 7 навыков высокоэффективных людей . Другими словами, процесс объяснения основан на эмпатии — важной способности понимать и разделять чувства другого человека
  • Формулирование объяснения помогает на лучше понимать идею
  • Основная причина множества неудачных объяснений — «проклятие знания», так как оно снижает нашу способность правильно оценивать аудиторию или собеседника
  • Хорошие объяснения повышают уверенность в себе, плохие — снижают или полностью уничтожают
  • Контекст — важная часть объяснения, которая делает идею, факт или историю понятнее и полезнее. И если аудитория разношерстная, другими словами, присутствуют и эксперты и новички, необходимо формировать контекст с уровня начинающим, а затем покрывать экспертов
  • Основной вопрос любого объяснения: почему это должно меня интересовать? При эффективном использовании, контекст помогает ответить на этот вопрос, создавая ощущение согласия по поводу предмета в целом
  • История. Цель истории в объяснении — добавить к изложению фактов человеческие переживания. Не нужно быть профессиональным рассказчиком, чтобы использовать истории. Истории используются, чтобы заинтересовать предметом объяснения
  • Истории чаще подходят для объяснений, где главная тема связана с действиями человека или с его опытом
  • Связи, как аналогии. Связи со старым способом, представленные в виде отчаяния или проблемы, делают необходимость новых решений ясной и понятной. Пример связи нового и старого: Google Docs это как Word но удобнее для совместной работы с файлом.
  • Использование связей — это еще один способ укрепить уверенность людей и снизить цену понимания определенного вопроса
  • При объяснении, Историю или Связь можно использовать, как совместно, так и отдельно, т.е. не обязательно применять их обоих для объяснения одного предмета
  • Описание — новая ступень объяснения. Применяется когда необходимо ответить на вопрос «как я могу это использовать?» вместо «почему меня это должно интересовать?» (о котором уже позаботились Контекст, История и Связь)
  • Упрощение используется, когда необходимо сложную идею сделать простой. С любой сложной идеей можно так поступить. Правила упрощения:
    • Не делать предположений о том, что люди уже знают
    • Использовать самые простые слова
    • Мысленно уменьшить масштаб предмета объяснения
    • Забыть о подробностях и исключениях
    • Жертвовать точностью ради понимания
    • Связать базовые идеи с тем, что понимает аудитория
  • Ограничения с которыми мы сталкиваемся, когда формируем объяснения. Хотя они и ограничивают, на самом деле, они и освобождают. Мы намеренно создаем «контейнер», который позволяет быстро решить, что положить внутрь, а что оставить снаружи и выкинуть из головы, чтобы сосредоточиться на других вопросах
  • Сценарий объединяет все части объяснения: контекст, связь, историю, описание, и в сценарии они принимают форму. Краткий обзор элементов сценария по порядку:
    • соглашение
    • контекст — проблема/отчаяние и нахождение решения
    • история
    • связь
    • описание
    • реализация решения — как
    • призыв к действию
  • Некоторые идеи трудно понять без иллюстрации, т.е. слов не всегда бывает достаточно. Такие идеи становятся понятными после того, как мы включаем визуализацию:
    • графики и временные графики
    • диаграммы
    • карты
    • блок-схемы
    • портреты пользователей

Впечатления о книге — Remote. Офис не обязателен — Джейсона Фрайда

Обложка книги Remote. Офис не обязателен

Книга от основателей компании 37signals, Джейсона Фрайда и Дэвида Хайнемайера Хенссона (так же известен как создатель известного фреймворка Ruby on rails). Личности достаточно известные, отчего их, кристаллизированные в книге, мысли, идеи, подходы имеют высокую ценность.

Данное произведение написано в 2013-2014 годах и тогда тренд на удаленную работу только начинал зарождаться. От этого, в том числе, значительная часть книги описывает преимущества удаленной работы (которые в 2021 году уже кажутся очевидными) и приемы разговоров с начальниками, чтобы склонить их к рассмотрению перспективы перехода на «удаленку».

Авторы считают что для успешного функционирования мозгу нужны апдейты. И цель этой книги — такой апдейт обеспечить. Как позиционируют Джейсон и Дэвид, на страницах книги будет показано множество преимуществ удаленной работы, включая доступ к наиболее талантливым исполнителям, отказ от выматывающих поездок на работу и обратно, рост производительности по сравнению с традиционными офисами, так же будут разобраны обычные отговорки противников этой идеи.

Отмечу некоторые ключевые моменты книги, которые заинтересовали меня лично…

  • Типичный офис стал «зоной прерываний», в которой каждый сегмент времени наполнен телеконференциями, созвонами, синхронизациями, встречами, совещаниями и прочими стандартными, но необязательными с точки зрения работы прерываниями. Осмысленная, творческая, сложная и важная работа требует длительных периодов концентрации, когда ничто не отвлекает и можно с головой погрузиться в то, чем занимаешься. Кстати, это посвящена целая исследовательская работа, описанная в предыдущей статье о книге «В работу с головой. Паттерны успеха от IT-специалиста».
  • Для успешной удаленной работы необходимо разработать подходящий распорядок дня и придерживаться его. Для этого нужно выйти на новый уровень личной ответственности. Это более высокий уровень, чем может показаться вначале, особенно для тех, кто от природы склонен откладывать дела на потом.
  • Большинство страхов, связанных с к удаленной работе возникают из-за недоверия к людям. А люди обладают поразительной особенностью отвечать вашим ожиданиям. Вот такой замкнутый круг, из которого жизненно-важно выходить. Так же можно резюмировать, что не стоит брать на работу того, кому не сможешь доверять и работать на босса, который не доверяет тебе.
  • Есть мнение, что дома люди чаще отвлекаются. Если и так, то лучший способ бороться с отвлекающими факторами — интересное, захватывающее дело. Большинство людей хотят работать, поскольку это тонизирует их и приносит удовольствие.
  • Время от времени — например, когда ситуация на работе становится напряженной — могут портиться даже отношения между добро-желательно настроенными людьми. Лучший способ не допустить этого — иметь на борту как можно больше оптимистов, тех, кто делает все возможное, чтобы у всех было отличное настроение.
  • Важно не только учитывать характер нанимаемых сотрудников, но и постоянно следить за атмосферой в коллективе. Не стоит позволять неприятным людям отравлять жизнь другим. В случае удаленной работы это смертельно опасно.
  • При подборе удаленных работников нужно особенно внимательно относиться к поощрению культурного разнообразия и личного развития. А так же поддерживать развитие команды.
  • Если рассматривать принятую разницу зарплат между столицей, крупными городами и провинцией, не стоит позволять относиться к себе как к второсортному работнику лишь из-за того, что живешь не в мегаполисе, вы можете спровоцировать аналогичное пренебрежительное отношение к себе и в остальных вопросах. Так же и с нанимающей стороны, не стоит поощрять такую дифференциацию вознаграждений для своих работников.
  • Удаленная работа ускоряет процесс «высадки» неправильных людей и появлении «на борту» людей правильных
  • Умение хорошо писать является важной чертой эффективного удаленного сотрудника. Чтобы получать такой навык (и многие другие) нужно много читать и изучать методы работы хороших писателей.
  • Самый точный способ оценить человека, при соискании на должность, — нанять его для выполнения небольшого задания, прежде чем решиться доверить большой проект.
  • При приеме на работу, личная встреча помогает понять последнее: нравится ли нам кандидат как человек. Необходимо пригласить человека на обед или же в офис, в результате, можно будет понять, комфортно ли ему с нами, и, комфортно ли нам с ним.
  • Вам, как руководителю, придется принять как данность, что ваши подчиненные будут ошибаться — конечно, непреднамеренно — и что эти ошибки — обычная плата за их обучение и независимость.
  • На самом деле, главным врагом удаленной работы является не «недо-«, а переработка. Это могло бы выглядеть как мечта работодателя: сотрудники во всю трудятся сверхурочно, не требуя за это компенсацию. Однако, если работа поглощает целиком, повышается вероятность «выгорания«. Это случается, даже когда человек любит свое дело.
  • Культура переработки легче складывается в компаниях, где суперменов-трудоголиков постоянно играют «наверху».
  • Попытки подстегнуть мотивацию угрозами или наградами абсолютно неэффективны. На самом деле они приводят к противоположному эффекту. Есть только один надежный способ поднять мотивацию — поощрять людей работать на тем, что им нравится, и только с теми людьми, которые не оставляют их равнодушными.
  • Смена декораций может способствовать появлению множества различных плодотворных идей.

Впечатления о книге — В работу с головой. Паттерны успеха от IT-специалиста Кэла Ньюпорта

Казалось бы, всем очевидно, что углубленная вдумчивая работа имеет только положительный эффект. И объяснять не нужно, как она благотворно влияет на результаты любой умственной деятельности. Здесь можно было бы поставить точку.

Но читая книгу «В работу с головой. Паттерны успеха от IT-специалиста», понимаешь, что тема далеко не простая. И, одно дело, понимать эффективность углубленной деятельности, а другое — уметь входить в это состояние.

Автор, в своем произведении, всесторонне исследует углубленную работу: какова ее ценность и значение, как в действительности редко она встречается, как входить в состояние углубленных активностей, как работать сосредоточенно и поддерживать это состояние. И замечает, что это еще сложнее в наше время социальных сетей, мессенджеров с электронных почт. В тексте, отдельно, отмечается, что, как это не парадоксально, способность погружаться в работу становится все более редкой как раз в то время , когда она приобретает все большую ценность для экономики.

Данная книга — своего рода научная работа, посвященная одному вопросу — сосредоточении на работе. Но доносится простым мотивирующим языком.

Хотя, реально, первые 40% книги автор, хоть и различными способами, но, просто, убеждает в том, что углубленная работа о-о-очень важна.

Материал изобилует историями и примерами очень знаменитых личностей и чуть менее известных. На страницах вы найдете подходы от Билла Гейтса, Чарльза Дарвина, Карла Юнга, Теодор Рузвельт, Дж. К. Роулинг, Джека Дорси, Энди Гроува, Уолтера Айзексона, Джерри Сайнфелда, Рика Фаррера, Михая Чиксентмихайи, Сантьяго Гонсалеса, Дэвида Девэйна, Брайана Чаппелла, Нила Стивенсона, Дональда Кнута и многих других.

Как программисту, мне очень интересны вопросы качества и эффективности работы. И для обучения такому непростому искусству как программирование, необходимо пристальное, безраздельное сосредоточение на концепциях, требующих интеллектуального напряжения. Чтобы выполнять работу качественно, необходимо в нее углубиться. Приступая к очередной сложной задаче, на собственном опыте замечено, что, прежде чем выполнять ее, необходимо собрать «контекст», другими словами погрузиться в переплетения связей между функциями, компонентами, зависимостями. Положить это все в «оперативную память» мозга. При этом, любое отвлечение может выбросить многие важные связи, что приводит к дополнительному времени для погружения.

Выделяется 4 способа погружения в работу:

  • «Монашеская» система. Эта система пытается увеличить объем углубленного труда посредством исключения или радикального уменьшения поверхностных обязанностей. Применима для людей, чей профессиональный спех в первую очередь зависит от выполнения этой единственной задачи на высочайшем уровне. Примерами могут быть ученые, работающие над важной научной работой, или писатели, сидящие над книгой.
  • Двухрежимная система. При этом, происходит распределение времени: какие то четко определенные отрезки (дни, недели, месяца) посвящаются углубленной работе, а оставшееся время открыты для всего прочего. Если, например, уделять такой работе лишь несколько часов по утрам, это время окажется слишком коротким, чтобы считать его периодом углубленной работы.
  • Ритмическая система. Цель здесь — задать в работе определенный ритм, который освободит вас от необходимости тратить энергию на решения, надо ли вам погружаться в работу, и если надо, то когда. Ритмическая система чрезвычайно широко распространена среди офисных работников.
  • Журналистская система. Подход, при котором вы вставляете углубленную работу в свое расписание в любой подходящий момент.

Какие еще моменты из книги я отметил для себя:

  • В любом случае, очень важна постановка цели, от достижения которой вы будете ожидать конкретных и весомых плодов в своей профессиональной области. В этом случае поток энтузиазма станет значительно более мощным
  • С окончанием рабочего дня следует отказаться до следующего утра от любых размышлениях о рабочих материях. Никакой вечерней проверки почты или слэка, никаких мысленных проигрываний заново рабочих диалогов, никаких планов насчет того, как вы собираетесь приступить к очередной задаче. Если вам не хватило времени, увеличьте свой рабочий день, но после того, как вы закончили, ваш ум должен быть свободен, чтобы в нем нашлось место «для лютиков, лесных клопов и звезд»
  • Возможности человека к углубленной работе на протяжении дня ограничены
  • Каждый рывок представляет собой сессию, на протяжении которой вы потенциально ощущаете скуку и очень хотите предаться поиску новых стимулов — но сопротивляетесь этим чувствам. Чем больше вы практикуете такое сопротивление, тем легче вас становится сопротивляться
  • Если вы хотите избавиться от соблазна развлекательных сайтов, высасывающих ваше время и внимание, предоставьте своему уму качественную альтернативу. Это не только сохранит вашу способность сопротивляться отвлечениям и сосредоточиваться — возможно, вам даже удастся осуществить высокую цель: пережить, возможно впервые в жизни, что значит действительно жить, а не просто существовать