Недавно я узнал об интересном формате мероприятия.
Fuck Up Nights — встречи предпринимателей для публичного обсуждения неудачных бизнес-проектов. Это движение возникло в 2012 году в Мексике и распространилось по всему миру.
Говорят, идея таких встреч родилась в баре, когда несколько подвыпивших приятелей поделились друг с другом историями своих неудач.
На каждой встрече 3-4 спикера рассказывают истории своих неудач в течение 7 минут с минимальной презентацией. После каждого выступления идет публичная дискуссия за бокалом вина. Идеально!
Неудачи порой могут научить гораздо большему, чем истории успеха. К слову, в этом канале я также делюсь нашими неудачами по тегу #инциденты. Мы все совершаем ошибки, и это нормально.
Некоторые истории могут звучать забавно, но каждая из них несет какую-то мораль. Учиться на чужих ошибках — гораздо менее болезненный способ получить опыт :)
Кто-нибудь участвовал в Fuck Up Nights? А для разработчиков нечто похожее проводят?
#инциденты
Fuck Up Nights — встречи предпринимателей для публичного обсуждения неудачных бизнес-проектов. Это движение возникло в 2012 году в Мексике и распространилось по всему миру.
Говорят, идея таких встреч родилась в баре, когда несколько подвыпивших приятелей поделились друг с другом историями своих неудач.
На каждой встрече 3-4 спикера рассказывают истории своих неудач в течение 7 минут с минимальной презентацией. После каждого выступления идет публичная дискуссия за бокалом вина. Идеально!
Неудачи порой могут научить гораздо большему, чем истории успеха. К слову, в этом канале я также делюсь нашими неудачами по тегу #инциденты. Мы все совершаем ошибки, и это нормально.
Некоторые истории могут звучать забавно, но каждая из них несет какую-то мораль. Учиться на чужих ошибках — гораздо менее болезненный способ получить опыт :)
Кто-нибудь участвовал в Fuck Up Nights? А для разработчиков нечто похожее проводят?
#инциденты
Еще в универе я сохранял копии файлов, чтобы не потерять драгоценные правки. В итоге в папке появлялись файлы вида "lab2.doc", "lab-final.doc" и даже "lab-final-last2.doc"!
Потом я узнал о существовании систем контроля версий, решающих задачу сохранения истории более изящно и технологично.
Когда я пришел в Яндекс, компания уже перешла с устаревшей CVS на Svn. Тогда у каждой команды в распоряжении было по 1-2 репозитория, а сделанные коммиты читали через почтовую рассылку. Ревью кода проводилось ответом на письмо с коммитом :)
Мы с моим руководителем хотели шагнуть в будущее — начать использовать Git с удобными локальными ветками. Чтобы не мигрировать всю команду, мы стали использовать git-svn.
Через какое-то время вся компания начала использовать Git. У нас даже появились свои внутренние инстансы GitHub и Bitbucket. Количество репозиториев стало расти, как и транзакционные издержки по интеграции кода.
Также стали появляться крупные репозитории с огромной по размеру историей. Скачивались такие репозитории целую вечность!
Во всех крупных компаниях рано или поздно появляется монорепозиторий. Яндекс не стал исключением, и у нас появилась Аркадия.
Можно долго спорить о плюсах и минусах монорепозитория. Это холиварная тема, и я не буду вас убеждать, что монорепозиторий — "серебряная пуля" для решения всех проблем. О бенефитах монорепозитория можно почитать на сайте monorepo.tools.
Для работы с Аркадией мы используем свою систему контроля версий под названием — Arc.
Arc — легковесная система контроля версий для монорепозитория:
- данные хранятся в облаке
- используется виртуализация рабочей копии вместо скачивания всех данных репозитория.
Такой подход позволяет хранить на диске только локальные изменения для повышения скорости работы.
Интерфейс Arc очень похож на Git. Если у разработчика был опыт работы с Git, то он без труда разберется с Arc. Доступны локальные ветки, стейджинг и быстрый просмотр истории коммитов. И это при том, что в этот репозиторий коммитит почти весь Яндекс!
Arc — yet another система контроля версий, свой велосипед. Но это очень хороший велосипед, который верой и правдой служит нам каждый день.
Несколько лет назад в одной иностранной социальной сети, похожей на VK, было два монорепозитория: весь код и фронтенд. В Аркадии лежит и код бекенда, и код фронтенда. Работать с этим кодом можно быстро и удобно. И с каждым годом становится все лучше ;)
#разработка
Потом я узнал о существовании систем контроля версий, решающих задачу сохранения истории более изящно и технологично.
Когда я пришел в Яндекс, компания уже перешла с устаревшей CVS на Svn. Тогда у каждой команды в распоряжении было по 1-2 репозитория, а сделанные коммиты читали через почтовую рассылку. Ревью кода проводилось ответом на письмо с коммитом :)
Мы с моим руководителем хотели шагнуть в будущее — начать использовать Git с удобными локальными ветками. Чтобы не мигрировать всю команду, мы стали использовать git-svn.
Через какое-то время вся компания начала использовать Git. У нас даже появились свои внутренние инстансы GitHub и Bitbucket. Количество репозиториев стало расти, как и транзакционные издержки по интеграции кода.
Также стали появляться крупные репозитории с огромной по размеру историей. Скачивались такие репозитории целую вечность!
Во всех крупных компаниях рано или поздно появляется монорепозиторий. Яндекс не стал исключением, и у нас появилась Аркадия.
Можно долго спорить о плюсах и минусах монорепозитория. Это холиварная тема, и я не буду вас убеждать, что монорепозиторий — "серебряная пуля" для решения всех проблем. О бенефитах монорепозитория можно почитать на сайте monorepo.tools.
Для работы с Аркадией мы используем свою систему контроля версий под названием — Arc.
Arc — легковесная система контроля версий для монорепозитория:
- данные хранятся в облаке
- используется виртуализация рабочей копии вместо скачивания всех данных репозитория.
Такой подход позволяет хранить на диске только локальные изменения для повышения скорости работы.
Интерфейс Arc очень похож на Git. Если у разработчика был опыт работы с Git, то он без труда разберется с Arc. Доступны локальные ветки, стейджинг и быстрый просмотр истории коммитов. И это при том, что в этот репозиторий коммитит почти весь Яндекс!
Arc — yet another система контроля версий, свой велосипед. Но это очень хороший велосипед, который верой и правдой служит нам каждый день.
Несколько лет назад в одной иностранной социальной сети, похожей на VK, было два монорепозитория: весь код и фронтенд. В Аркадии лежит и код бекенда, и код фронтенда. Работать с этим кодом можно быстро и удобно. И с каждым годом становится все лучше ;)
#разработка
На первом занятии по высшей математике в университете преподаватель Феоктистов В.В. нарисовал картинку человечков-треугольничков.
Уровень студентов на первом курсе был разным: от обычной школы до физмата. Для кого-то материал был новым, а кто-то его лишь повторял.
Основная идея преподавателя была следующей:
- усидчивых отличников обогнать невозможно, это гении
- неусидчивых троечников обычно отчисляют в первую очередь
- усидчивые троечники со временем обгоняют неусидчивых отличников
Так и оказалось. Самоуверенных неусидчивых отличников в итоге отчислили, а упорные троечники доучились и защитили дипломы. Но троечникам приходилось трудиться на порядок больше отличников. Подтверждаю этот факт, так как я был троечником.
Когда я пришел в Яндекс, то опять оказался троечником, так как меня окружали гораздо более умные и опытные коллеги. В итоге опять пришлось брать усидчивостью :)
Терпение и труд всё перетрут.
#карьера
Уровень студентов на первом курсе был разным: от обычной школы до физмата. Для кого-то материал был новым, а кто-то его лишь повторял.
Основная идея преподавателя была следующей:
- усидчивых отличников обогнать невозможно, это гении
- неусидчивых троечников обычно отчисляют в первую очередь
- усидчивые троечники со временем обгоняют неусидчивых отличников
Так и оказалось. Самоуверенных неусидчивых отличников в итоге отчислили, а упорные троечники доучились и защитили дипломы. Но троечникам приходилось трудиться на порядок больше отличников. Подтверждаю этот факт, так как я был троечником.
Когда я пришел в Яндекс, то опять оказался троечником, так как меня окружали гораздо более умные и опытные коллеги. В итоге опять пришлось брать усидчивостью :)
Терпение и труд всё перетрут.
#карьера
До Яндекса один техлид дал мне вредный совет: "Разработай свою CMS, подсади на нее всю компанию и стань тем единственным, кто сможет ее развивать".
Я придерживаюсь противоположного подхода: важно делиться знаниями и не замыкать все процессы на себя. Только так можно успешно развивать технологическую платформу, а в итоге делать больше и лучше.
Отсутствие внутренней документации — частая проблема в компаниях. Ведь нас хвалят за решенные задачи, а не за журналистику :)
Мой опыт работы документатором подсказывает, что с документацией можно работать также, как с кодом: писать, рефакторить, тестировать, деплоить.
Но как и с программированием, тут тоже важна практика.
Мне вспоминается серия из «Теории большого взрыва», в которой Леонард вспоминает, как Шелдон учился плавать с помощью Интернета. Обиженный Шелдон отвечает: «Я действительно учился плавать». На что Леонард говорит, что Шелдон учился плавать на полу. А тот возражает: «Навыки переносятся, мне просто было неинтересно пробовать в воде!»
Программисты читают много документации, но это не значит, что они сами смогут написать хорошую документацию. Нужно писать тексты, больше текстов.
Именно поэтому я всем вокруг повторяю, что важно публиковать технологические посты внутри Яндекса и снаружи, учиться описывать свои достижения к ревью и писать лаконичную документацию.
Тот, кто умеет структурно описывать свои мысли и решения, обладает конкурентным преимуществом. Порядок в мыслях — порядок в делах :)
#разработка
Я придерживаюсь противоположного подхода: важно делиться знаниями и не замыкать все процессы на себя. Только так можно успешно развивать технологическую платформу, а в итоге делать больше и лучше.
Отсутствие внутренней документации — частая проблема в компаниях. Ведь нас хвалят за решенные задачи, а не за журналистику :)
Мой опыт работы документатором подсказывает, что с документацией можно работать также, как с кодом: писать, рефакторить, тестировать, деплоить.
Но как и с программированием, тут тоже важна практика.
Мне вспоминается серия из «Теории большого взрыва», в которой Леонард вспоминает, как Шелдон учился плавать с помощью Интернета. Обиженный Шелдон отвечает: «Я действительно учился плавать». На что Леонард говорит, что Шелдон учился плавать на полу. А тот возражает: «Навыки переносятся, мне просто было неинтересно пробовать в воде!»
Программисты читают много документации, но это не значит, что они сами смогут написать хорошую документацию. Нужно писать тексты, больше текстов.
Именно поэтому я всем вокруг повторяю, что важно публиковать технологические посты внутри Яндекса и снаружи, учиться описывать свои достижения к ревью и писать лаконичную документацию.
Тот, кто умеет структурно описывать свои мысли и решения, обладает конкурентным преимуществом. Порядок в мыслях — порядок в делах :)
#разработка
Сегодня расскажу байку о терпении и его отсутствии. Без морали.
Этот случай произошел несколько лет назад. Я тогда сидел на месте первого мобильного стенда после его переезда.
Уже был поздний вечер, и только несколько самых стойких коллег продолжали работать. Ко мне подошел разработчик для обсуждения реализации нового модуля.
Работа программиста — сплошные компромиссы между скоростью, сложностью и качеством. Но иногда этот компромисс не так легко найти.
Новый модуль можно было сделать двумя способами:
1. Правильно и красиво, но попутно вызвать цунами рефакторингов в наших сервисах. Т.е. очень дорого.
2. Немного "срезать углы", чтобы получилось дешево и сердито.
Разработчик был перфекционистом до мозга костей и не хотел портить свою архитектурную красоту маленьким "костыликом". Для меня же важно было снизить нагрузку на команду.
И вот несколько часов мы пытались друг другу донести свою точку зрения, но все тщетно.
Дальше разработчик роняет фразу:
— Да это самодурство какое-то!
В Яндексе не принято говорить в приказном тоне, но тут мое терпение не выдержало:
— Я — начальник-самодур! Сделай, как я хочу! Это моя прихоть!
Когда я произнес эту фразу, в опенспейсе повисла тишина. Наверное, коллеги стали обдумывать, как теперь жить с таким самодуром рядом :)
P.S. Приказной аргумент в итоге все равно не подействовал, зато хоть коллег повеселил.
#байки
Этот случай произошел несколько лет назад. Я тогда сидел на месте первого мобильного стенда после его переезда.
Уже был поздний вечер, и только несколько самых стойких коллег продолжали работать. Ко мне подошел разработчик для обсуждения реализации нового модуля.
Работа программиста — сплошные компромиссы между скоростью, сложностью и качеством. Но иногда этот компромисс не так легко найти.
Новый модуль можно было сделать двумя способами:
1. Правильно и красиво, но попутно вызвать цунами рефакторингов в наших сервисах. Т.е. очень дорого.
2. Немного "срезать углы", чтобы получилось дешево и сердито.
Разработчик был перфекционистом до мозга костей и не хотел портить свою архитектурную красоту маленьким "костыликом". Для меня же важно было снизить нагрузку на команду.
И вот несколько часов мы пытались друг другу донести свою точку зрения, но все тщетно.
Дальше разработчик роняет фразу:
— Да это самодурство какое-то!
В Яндексе не принято говорить в приказном тоне, но тут мое терпение не выдержало:
— Я — начальник-самодур! Сделай, как я хочу! Это моя прихоть!
Когда я произнес эту фразу, в опенспейсе повисла тишина. Наверное, коллеги стали обдумывать, как теперь жить с таким самодуром рядом :)
P.S. Приказной аргумент в итоге все равно не подействовал, зато хоть коллег повеселил.
#байки
@digital_keks порекомендовал интересную статью — Strategic Thinking: Because Good Ideas Can Come From Anywhere.
Статья описывает два способа работы над стратегией: стратегическое планирование и стратегическое мышление.
При стратегическом планировании руководитель собирает данные и решает, в каком направлении должна двигаться компания для достижения своих целей.
Стратегическое мышление подразумевает, что над стратегией работает не только руководитель, но и остальные сотрудники компании. Это особенно ценно в настоящую эпоху бизнесовой турбулентности и постоянной изменчивости планов.
Т.е. любой сотрудник думает о бизнесе и как ему помочь. Это в частности означает, что если сотрудник обнаружил какую-то проблему или понимает, как что-то можно сделать лучше, то нужно про это рассказать, объяснить, доказать и тем самым повлиять на стратегию.
Не торопитесь говорить, что вы далеки от бизнеса. Косвенно можно повлиять на бизнес через улучшение инфраструктуры, ускорение приложения, упрощение процессов, написание документации или даже починкой багов.
Если что-то не работает или работает плохо, то почините.
Если руководитель ведет вас куда-то не туда, то скажите ему об этом.
Если есть смелая гипотеза, но она может быть "глупой", то расскажите о ней.
Не боги горшки обжигают. Руководители не всегда принимают правильные решения. Но вместе шанс придумать правильную стратегию точно выше ;)
#карьера
Статья описывает два способа работы над стратегией: стратегическое планирование и стратегическое мышление.
При стратегическом планировании руководитель собирает данные и решает, в каком направлении должна двигаться компания для достижения своих целей.
Стратегическое мышление подразумевает, что над стратегией работает не только руководитель, но и остальные сотрудники компании. Это особенно ценно в настоящую эпоху бизнесовой турбулентности и постоянной изменчивости планов.
Т.е. любой сотрудник думает о бизнесе и как ему помочь. Это в частности означает, что если сотрудник обнаружил какую-то проблему или понимает, как что-то можно сделать лучше, то нужно про это рассказать, объяснить, доказать и тем самым повлиять на стратегию.
Не торопитесь говорить, что вы далеки от бизнеса. Косвенно можно повлиять на бизнес через улучшение инфраструктуры, ускорение приложения, упрощение процессов, написание документации или даже починкой багов.
Если что-то не работает или работает плохо, то почините.
Если руководитель ведет вас куда-то не туда, то скажите ему об этом.
Если есть смелая гипотеза, но она может быть "глупой", то расскажите о ней.
Не боги горшки обжигают. Руководители не всегда принимают правильные решения. Но вместе шанс придумать правильную стратегию точно выше ;)
#карьера
Я уже рассказывал, что всем нам нужно научиться продавать идеи своим коллегам.
Помимо принципа "Не лгать!", хочу добавить еще один: "Лучше помочь, чем не помочь".
Если коллеге сложно что-то объяснить, то нужно найти подход.
Если договориться сложно, то нужно найти компромисс.
Если к вам обращаются, то найдите время как минимум на консультацию. А если позволяет время и ресурсы, то помогите.
Конечно, у всех из нас свои проекты и горящие сроки. Всегда катастрофически не хватает времени. Да и вообще, мои проекты — самые важные!
Благодаря хорошим личным отношениям проекты двигаются быстрее. С помощью формализма и бюрократии такого не добиться.
Приведу пример из своего опыта.
Для одной рабочей задачи мне нужно было опросить пару сотен пользователей о работе новой фичи. Мне пообещали провести опрос только через 2-3 недели.
Я не мог так долго ждать и обратился к своему коллеге — руководителю команды продаж. Эти ребята хорошо знают, как опрашивать пользователей и клиентов.
Примерно через час со мной связались его сотрудники, взяли на себя всю бюрократию и отдали результаты на следующий день! Для команды продаж с их настроенными процессами моя просьба была очень простой в реализации. Но для меня эта помощь была бесценной!
Оказалось, что их руководитель пришел к ним с фразой "Нужно помочь хорошему человеку". Ну как тут отказать?)
#карьера
Помимо принципа "Не лгать!", хочу добавить еще один: "Лучше помочь, чем не помочь".
Если коллеге сложно что-то объяснить, то нужно найти подход.
Если договориться сложно, то нужно найти компромисс.
Если к вам обращаются, то найдите время как минимум на консультацию. А если позволяет время и ресурсы, то помогите.
Конечно, у всех из нас свои проекты и горящие сроки. Всегда катастрофически не хватает времени. Да и вообще, мои проекты — самые важные!
Благодаря хорошим личным отношениям проекты двигаются быстрее. С помощью формализма и бюрократии такого не добиться.
Приведу пример из своего опыта.
Для одной рабочей задачи мне нужно было опросить пару сотен пользователей о работе новой фичи. Мне пообещали провести опрос только через 2-3 недели.
Я не мог так долго ждать и обратился к своему коллеге — руководителю команды продаж. Эти ребята хорошо знают, как опрашивать пользователей и клиентов.
Примерно через час со мной связались его сотрудники, взяли на себя всю бюрократию и отдали результаты на следующий день! Для команды продаж с их настроенными процессами моя просьба была очень простой в реализации. Но для меня эта помощь была бесценной!
Оказалось, что их руководитель пришел к ним с фразой "Нужно помочь хорошему человеку". Ну как тут отказать?)
#карьера
У нас в Яндексе принято говорить про две ветки развития разработчика:
— растить техническую экспертизу
— становиться руководителем
Тут мы немного лукавим. На высоких грейдах проекты становятся более сложными. Справиться с ними в одиночку или сложно, или невозможно.
Старшие разработчики вводят в курс дела своих коллег, рассказывают об устройстве проекта, декомпозируют крупные задачи, ревьюят код и т.д.
В итоге старший разработчик выполняет роль наставника или начинающего руководителя. Ведь руководство — готовность брать на себя ответственность не только за себя и за проект, но и за других людей.
Дальше и правда можно сделать выбор. Если продолжать брать на себя больше ответственности и работать с людьми, то в итоге становишься руководителем официально. Или же двигаться в сторону IC (Individual Contributor).
Быть руководителем — непросто. Оценивают не только личные достижения, но и достижения команды. Команда должна работать слаженно и эффективно.
А еще проекты, как правило, становятся более долгосрочными. Ждать заметного результата нужно дольше, и мотивация первое время может страдать. Но это только на время переходного периода. Проверено на себе)
Потом начинаешь ценить достижения команды гораздо выше своих личных. А это мотивирует делать команду еще сильнее.
Я помню, как один разработчик все время защищал комфорт своего рабочего места и боролся за место у окна. Но когда он стал руководителем, то все самое лучшее стал отдавать своим разработчикам. Чтобы команду ничего не отвлекало. Повзрослел :)
#руководство
— растить техническую экспертизу
— становиться руководителем
Тут мы немного лукавим. На высоких грейдах проекты становятся более сложными. Справиться с ними в одиночку или сложно, или невозможно.
Старшие разработчики вводят в курс дела своих коллег, рассказывают об устройстве проекта, декомпозируют крупные задачи, ревьюят код и т.д.
В итоге старший разработчик выполняет роль наставника или начинающего руководителя. Ведь руководство — готовность брать на себя ответственность не только за себя и за проект, но и за других людей.
Дальше и правда можно сделать выбор. Если продолжать брать на себя больше ответственности и работать с людьми, то в итоге становишься руководителем официально. Или же двигаться в сторону IC (Individual Contributor).
Быть руководителем — непросто. Оценивают не только личные достижения, но и достижения команды. Команда должна работать слаженно и эффективно.
А еще проекты, как правило, становятся более долгосрочными. Ждать заметного результата нужно дольше, и мотивация первое время может страдать. Но это только на время переходного периода. Проверено на себе)
Потом начинаешь ценить достижения команды гораздо выше своих личных. А это мотивирует делать команду еще сильнее.
Я помню, как один разработчик все время защищал комфорт своего рабочего места и боролся за место у окна. Но когда он стал руководителем, то все самое лучшее стал отдавать своим разработчикам. Чтобы команду ничего не отвлекало. Повзрослел :)
#руководство
В прошлом году я описывал свои принципы для повышения безопасности в Интернете. Один из важных пунктов — использование менеджера паролей для хранения паролей, данных о банковских картах и документах.
Расскажу в двух словах о менеджере паролей для тех, кто им ни разу не пользовался.
Менеджер паролей — приложение для компьютера и смартфона, а также плагин для браузера. При открытии приложение требует ввести мастер-пароль или использовать биометрию для входа и расшифровки данных. Все данные хранятся и синхронизируются в зашифрованном файле.
Я долгое время использовал 1Password от компании AgileBits. Это отличный менеджер паролей: более 15 лет на рынке, данные надежно шифруются, удобный и красивый интерфейс, классная поддержка.
В прошлом году 1Password анонсировал новую мажорную версию без поддержки local vaults. Остался единственный способ синхронизации данных — через сервера компании AgileBits и только по платной подписке.
На форуме 1Password развернулась эмоциональная дискуссия. Пользователи были возмущены. Основная претензия была не к платной подписке. Пользователи не хотели отдавать свои секреты и пароли компании AgileBits, а хотели хранить их и синхронизировать по своему усмотрению.
Я ждал, чем закончится дискуссия. К сожалению, позиция 1Password не изменилась. Пора менять менеджер паролей :)
К слову, русскоязычная часть пользователей стала жаловаться на проблемы с оплатой подписки. Не смог оплатить подписку и остался без своих данных — удручающая перспектива.
По совету коллег я посмотрел в сторону утилиты pass с шифрованием gpg-ключами. Способ для истинно упоротых айтишников. Не подошла эта утилита из-за медленного поиска. Каждый пароль хранится в отдельном шифрованном файле, и при поиске нужно расшифровывать сотни файлов (в моем случае), и это ОЧЕНЬ медленно.
Вторая рекомендация — использовать KeePass. Мое чувство прекрасного страдало из-за вырвиглазного UX официального приложения. Но среди неофициальных клиентов я нашел StrongBox.
StrongBox визуально чем-то похож на 1Password, но все шифрованные данные хранит в формате KeePass. В любой момент можно легко переехать в другое приложение.
Буквально 5 минут потребовалось, чтобы мигрировать из 1Password в StrongBox. В течение 3х месячного триала StrongBox я перестал пользоваться 1Password. После триала купил пожизненную лицензию StrongBox.
Сперва было непривычно, но потом быстро освоился. По возможностям не уступает 1Password, и можно синхронизировать данные так, как хочется.
Если вы искали менеджер паролей и вы — пользователь продуктов Apple, то обратите внимание на StrongBox.
#безопасность
Расскажу в двух словах о менеджере паролей для тех, кто им ни разу не пользовался.
Менеджер паролей — приложение для компьютера и смартфона, а также плагин для браузера. При открытии приложение требует ввести мастер-пароль или использовать биометрию для входа и расшифровки данных. Все данные хранятся и синхронизируются в зашифрованном файле.
Я долгое время использовал 1Password от компании AgileBits. Это отличный менеджер паролей: более 15 лет на рынке, данные надежно шифруются, удобный и красивый интерфейс, классная поддержка.
В прошлом году 1Password анонсировал новую мажорную версию без поддержки local vaults. Остался единственный способ синхронизации данных — через сервера компании AgileBits и только по платной подписке.
На форуме 1Password развернулась эмоциональная дискуссия. Пользователи были возмущены. Основная претензия была не к платной подписке. Пользователи не хотели отдавать свои секреты и пароли компании AgileBits, а хотели хранить их и синхронизировать по своему усмотрению.
Я ждал, чем закончится дискуссия. К сожалению, позиция 1Password не изменилась. Пора менять менеджер паролей :)
К слову, русскоязычная часть пользователей стала жаловаться на проблемы с оплатой подписки. Не смог оплатить подписку и остался без своих данных — удручающая перспектива.
По совету коллег я посмотрел в сторону утилиты pass с шифрованием gpg-ключами. Способ для истинно упоротых айтишников. Не подошла эта утилита из-за медленного поиска. Каждый пароль хранится в отдельном шифрованном файле, и при поиске нужно расшифровывать сотни файлов (в моем случае), и это ОЧЕНЬ медленно.
Вторая рекомендация — использовать KeePass. Мое чувство прекрасного страдало из-за вырвиглазного UX официального приложения. Но среди неофициальных клиентов я нашел StrongBox.
StrongBox визуально чем-то похож на 1Password, но все шифрованные данные хранит в формате KeePass. В любой момент можно легко переехать в другое приложение.
Буквально 5 минут потребовалось, чтобы мигрировать из 1Password в StrongBox. В течение 3х месячного триала StrongBox я перестал пользоваться 1Password. После триала купил пожизненную лицензию StrongBox.
Сперва было непривычно, но потом быстро освоился. По возможностям не уступает 1Password, и можно синхронизировать данные так, как хочется.
Если вы искали менеджер паролей и вы — пользователь продуктов Apple, то обратите внимание на StrongBox.
#безопасность
Прочитал книгу Форма жизни №4: Как остаться человеком в эпоху расцвета искусственного интеллекта от Евгения Черешнева.
Мне нравится взгляд Евгения на кибербезопасность, искусственный интеллект и возможные варианты нашего будущего.
Первая форма жизни — одноклеточные существа.
Вторая форма жизни — человек разумный.
Третья форма жизни — AI.
Четвертая форма жизни — симбиоз человека и AI.
Крупные компании собирают наши данные и используют их для заработка. Причем с пользователями не делятся :)
Все больше собираемых данных укладывается в зону "неизвестное" окна Джохари, т.е. это информация о нас, которую и мы не знаем, и наше окружение не знает.
В свое время я с удивлением обнаружил, сколько разных данных натрекали мои Apple Watch. К слову, часы уже научились меня хвалить за правильное мытье рук :)
Приведу несколько интересных, на мой взгляд, фрагментов из его книги.
Про человека:
«Человек — это самообучающийся биокомпьютер с конечным сроком годности, поведение которого можно предсказать с высокой точностью, если иметь достаточно данных о методах его обучения и фаетического поведения в прошлом, разбитого по четким и рассчитываемым, размеченным блокам»
Про цифровую ДНК:
«В сухом остатке с точки зрения данных жизнь — всего лишь отрезок длиной 44,7 млн минут. 44706000, если быть точнее (исходя из продолжительности жизни 85 лет, что само по себе оптимистично). Если использовать минутную сетку, в вашей базе данных может быть, условно, 44,7 млн записей. Это все, что после вас останется, когда ваше «железо» перестанет дышать. Этот цифровой след, состоящий из 15 типов данных, о которых мы говорили ранее, и выводы о вашей жизни, которые можно на нем построить, и есть ваша цифровая ДНК, или digital DNA (dDNA).»
Про влияние AI на человечество:
«В декабре 2017 года консалтинговая компания McKinsey выпустила 150-страничный отчет, в котором спрогнозировала исчезновение от 400 до 800 млн рабочих мест к 2030 году за счет внедрения инструментов автоматизации, роботизации и искусственного интеллекта... никогда в истории мы еще не сталкивались с такими масштабами перемен: представьте для простоты, что к 2030 году население Северной и Южной Америк (население стран Латинской Америки — 642 млн, США — 328 млн, Канады — 38 млн) оказалось без работы»
Про Timecoins:
«Не будем отрываться от реальности — вспомним о работе, учебе, семье, телевизоре, отведем 10 000 часов на то, чтобы стать профессионалом в какой-либо области, добавим немного времени на другие занятия — и окажется, что в жизни здорового человека отведено место примерно для 1000 книг. Всего 1000!!! Думаю, можно смело экстраполировать этот подход и на другие типы контента, но вы только вдумайтесь: количество новостей, книг и постов, которые вы можете прочитать, — конечно. Каждый день мы расплачиваемся за покупки в iTunes, на Amazon и в супермаркетах даже не деньгами, а Абсолютной Криптовалютой — Временем, Timecoins. Мы майним эти монетки каждый день и за всю жизнь можем намайнить около 80 лет. И что-то с ними сделать. Или не сделать. Могу я предложить способ удачно вложиться? Читайте — начните со 100 лучших книг человечества (условно, «откатать для начала обязательную программу») — настоятельно рекомендую начать прямо сегодня, например с «Капитанской дочки» Пушкина (в конце книги я привел свою версию топ-100 книг всех времен и народов, пользуйтесь).
Кстати, спасибо, что тратите часть своих таймкойнов на чтение моих постов! ;)
#книги
Мне нравится взгляд Евгения на кибербезопасность, искусственный интеллект и возможные варианты нашего будущего.
Первая форма жизни — одноклеточные существа.
Вторая форма жизни — человек разумный.
Третья форма жизни — AI.
Четвертая форма жизни — симбиоз человека и AI.
Крупные компании собирают наши данные и используют их для заработка. Причем с пользователями не делятся :)
Все больше собираемых данных укладывается в зону "неизвестное" окна Джохари, т.е. это информация о нас, которую и мы не знаем, и наше окружение не знает.
В свое время я с удивлением обнаружил, сколько разных данных натрекали мои Apple Watch. К слову, часы уже научились меня хвалить за правильное мытье рук :)
Приведу несколько интересных, на мой взгляд, фрагментов из его книги.
Про человека:
«Человек — это самообучающийся биокомпьютер с конечным сроком годности, поведение которого можно предсказать с высокой точностью, если иметь достаточно данных о методах его обучения и фаетического поведения в прошлом, разбитого по четким и рассчитываемым, размеченным блокам»
Про цифровую ДНК:
«В сухом остатке с точки зрения данных жизнь — всего лишь отрезок длиной 44,7 млн минут. 44706000, если быть точнее (исходя из продолжительности жизни 85 лет, что само по себе оптимистично). Если использовать минутную сетку, в вашей базе данных может быть, условно, 44,7 млн записей. Это все, что после вас останется, когда ваше «железо» перестанет дышать. Этот цифровой след, состоящий из 15 типов данных, о которых мы говорили ранее, и выводы о вашей жизни, которые можно на нем построить, и есть ваша цифровая ДНК, или digital DNA (dDNA).»
Про влияние AI на человечество:
«В декабре 2017 года консалтинговая компания McKinsey выпустила 150-страничный отчет, в котором спрогнозировала исчезновение от 400 до 800 млн рабочих мест к 2030 году за счет внедрения инструментов автоматизации, роботизации и искусственного интеллекта... никогда в истории мы еще не сталкивались с такими масштабами перемен: представьте для простоты, что к 2030 году население Северной и Южной Америк (население стран Латинской Америки — 642 млн, США — 328 млн, Канады — 38 млн) оказалось без работы»
Про Timecoins:
«Не будем отрываться от реальности — вспомним о работе, учебе, семье, телевизоре, отведем 10 000 часов на то, чтобы стать профессионалом в какой-либо области, добавим немного времени на другие занятия — и окажется, что в жизни здорового человека отведено место примерно для 1000 книг. Всего 1000!!! Думаю, можно смело экстраполировать этот подход и на другие типы контента, но вы только вдумайтесь: количество новостей, книг и постов, которые вы можете прочитать, — конечно. Каждый день мы расплачиваемся за покупки в iTunes, на Amazon и в супермаркетах даже не деньгами, а Абсолютной Криптовалютой — Временем, Timecoins. Мы майним эти монетки каждый день и за всю жизнь можем намайнить около 80 лет. И что-то с ними сделать. Или не сделать. Могу я предложить способ удачно вложиться? Читайте — начните со 100 лучших книг человечества (условно, «откатать для начала обязательную программу») — настоятельно рекомендую начать прямо сегодня, например с «Капитанской дочки» Пушкина (в конце книги я привел свою версию топ-100 книг всех времен и народов, пользуйтесь).
Кстати, спасибо, что тратите часть своих таймкойнов на чтение моих постов! ;)
#книги
Мы живем в эпоху капитализма с конкурирующими бизнесами. Как и в природе, бизнесы конкурируют друг с другом, кусаются, обороняются или даже поглощают друг друга.
Для выживания бизнесы зарабатывают деньги. Часть прибыли уходит на развитие бизнеса для ускорения роста и укрепления своих позиций, другая часть — на расходы.
Сотрудникам компании же особенно интересна часть расходов, которую компания тратит на персонал. А точнее на зарплаты и премии.
В IT компаниях люди — основная статья расходов, т.к. люди — это главное.
Владельцам компании необходимо решать непростую задачу по распределению денег среди сотрудников компании. И это очень сложная задача, которую помогает решать ревью.
Я вспоминаю управление бюджетом до внедрения системы ревью:
- повышение зарплаты не регламентировалось и отдавалось на откуп руководителю (непонятно, когда повышать зарплату и на сколько)
- в нашей команде для премий была придумана "коммунальная система": оценивали запуски баллами, накапливали их, и потом все получали премию в 1 оклад (понятен размер премии, но непонятно когда)
Даже управление бюджетом небольшого подразделения — головная боль! Непонятно, как справедливо распределить бюджет. Сравнивались только достижения внутри одного подразделения, что приводило к разным компенсациям за одну и ту же работу в пределах компании.
Сотрудники вообще не понимали, когда ждать повышения зарплаты. Я слышал историю о руководителе, который забыл повысить зарплату одному из сотрудников, т.к. сотрудник не напоминал об этом деликатном вопросе! 🙈
Ревью добавило цикличности и предсказуемости. Калибровать результаты стали между разными подразделениями. Результаты стали более объективными.
Да, процесс не полностью прозрачен. Но он, правда, гораздо прозрачнее того, что было раньше :)
#ревью
Для выживания бизнесы зарабатывают деньги. Часть прибыли уходит на развитие бизнеса для ускорения роста и укрепления своих позиций, другая часть — на расходы.
Сотрудникам компании же особенно интересна часть расходов, которую компания тратит на персонал. А точнее на зарплаты и премии.
В IT компаниях люди — основная статья расходов, т.к. люди — это главное.
Владельцам компании необходимо решать непростую задачу по распределению денег среди сотрудников компании. И это очень сложная задача, которую помогает решать ревью.
Я вспоминаю управление бюджетом до внедрения системы ревью:
- повышение зарплаты не регламентировалось и отдавалось на откуп руководителю (непонятно, когда повышать зарплату и на сколько)
- в нашей команде для премий была придумана "коммунальная система": оценивали запуски баллами, накапливали их, и потом все получали премию в 1 оклад (понятен размер премии, но непонятно когда)
Даже управление бюджетом небольшого подразделения — головная боль! Непонятно, как справедливо распределить бюджет. Сравнивались только достижения внутри одного подразделения, что приводило к разным компенсациям за одну и ту же работу в пределах компании.
Сотрудники вообще не понимали, когда ждать повышения зарплаты. Я слышал историю о руководителе, который забыл повысить зарплату одному из сотрудников, т.к. сотрудник не напоминал об этом деликатном вопросе! 🙈
Ревью добавило цикличности и предсказуемости. Калибровать результаты стали между разными подразделениями. Результаты стали более объективными.
Да, процесс не полностью прозрачен. Но он, правда, гораздо прозрачнее того, что было раньше :)
#ревью
Я люблю улучшения UX обыденных задач. Например, оффлайн похода за покупками. Не все же заказывать онлайн?
В 2017 году Amazon запустил магазин без кассиров, но эти магазины не прижились. Получилось технологично, но дорого для масштабирования.
Uniqlo итеративно улучшает текущий процесс. Ниже расскажу про свой недавний опыт.
Я набрал товары в корзинку и пошел к киоску самообслуживания. Приготовился "пропикивать" кучу разной мелочевки. Но ничего такого не произошло :)
Поставил корзинку в специальное углубление, а киоск сам определил список купленных товаров и вывел итоговую сумму к оплате. Магия!
Никакой магии, конечно, нет. Каждая вещь в Uniqlo снабжена пассивной RFID меткой с информацией о товаре. Киоск считывает RFID метки и производит простейшие арифметические действия.
Решение Uniqlo, в отличие от Amazon — простое и эффективное. И самое главное — легко масштабируемое на практически любые магазины.
В 2017 году Amazon запустил магазин без кассиров, но эти магазины не прижились. Получилось технологично, но дорого для масштабирования.
Uniqlo итеративно улучшает текущий процесс. Ниже расскажу про свой недавний опыт.
Я набрал товары в корзинку и пошел к киоску самообслуживания. Приготовился "пропикивать" кучу разной мелочевки. Но ничего такого не произошло :)
Поставил корзинку в специальное углубление, а киоск сам определил список купленных товаров и вывел итоговую сумму к оплате. Магия!
Никакой магии, конечно, нет. Каждая вещь в Uniqlo снабжена пассивной RFID меткой с информацией о товаре. Киоск считывает RFID метки и производит простейшие арифметические действия.
Решение Uniqlo, в отличие от Amazon — простое и эффективное. И самое главное — легко масштабируемое на практически любые магазины.
Я уже рассказывал о нашей прошлой системе выкладки сервисов — с помощью debian-пакетов и даже написал лонгрид с подробностями.
Перед установкой debian-пакета необходимо настроить сервер. Но если двум разным пакетам понадобится разное окружение, то возникает проблема.
Нужно либо каким-то образом "поженить" конфликтующие окружения на одном сервере, либо ставить такие debian-пакеты на разные сервера.
Чаще всего один физический сервер разделяют на независимые части с помощью виртуализации для оптимизации использования мощностей. И на такие виртуальные сервера можно поставить конфликтующие debian-пакеты с сервисами.
Но можно пойти немного дальше и воспользоваться контейнеризацией с созданием независимых виртуальных операционных систем.
Docker — де-факто стандарт контейнеризации. Docker-контейнеры используются повсеместно — и в Яндексе, в частности.
В отличие от debian-пакета в docker-контейнер включено необходимое окружение. Однажды настроенный docker-контейнер может быть запущен на любых серверах. Удобно обновлять и поддерживать.
Docker позволяет легко накатывать и откатывать новую версию приложения. И это с учетом изолированности среды выполнения и минимальным оверхедом по использованию ресурсов.
В моей команде docker используется не совсем по "канонам". В одном docker-контейнере одновременно живет несколько процессов: nginx, приложение и дополнительные вспомогательные процессы.
По-хорошему, их нужно было разносить по отдельным docker-контейнерам с провязкой через docker-compose, но нам оказалось удобнее сделать общий базовый образ "все в одном".
Docker-образ конкретного сервиса наследуется от базового образа и получает всю необходимую инфраструктуру "из коробки". Такой подход позволяет нам унифицированно работать с 50+ сервисами и упрощает обновление инфраструктуры.
#инфраструктура
Перед установкой debian-пакета необходимо настроить сервер. Но если двум разным пакетам понадобится разное окружение, то возникает проблема.
Нужно либо каким-то образом "поженить" конфликтующие окружения на одном сервере, либо ставить такие debian-пакеты на разные сервера.
Чаще всего один физический сервер разделяют на независимые части с помощью виртуализации для оптимизации использования мощностей. И на такие виртуальные сервера можно поставить конфликтующие debian-пакеты с сервисами.
Но можно пойти немного дальше и воспользоваться контейнеризацией с созданием независимых виртуальных операционных систем.
Docker — де-факто стандарт контейнеризации. Docker-контейнеры используются повсеместно — и в Яндексе, в частности.
В отличие от debian-пакета в docker-контейнер включено необходимое окружение. Однажды настроенный docker-контейнер может быть запущен на любых серверах. Удобно обновлять и поддерживать.
Docker позволяет легко накатывать и откатывать новую версию приложения. И это с учетом изолированности среды выполнения и минимальным оверхедом по использованию ресурсов.
В моей команде docker используется не совсем по "канонам". В одном docker-контейнере одновременно живет несколько процессов: nginx, приложение и дополнительные вспомогательные процессы.
По-хорошему, их нужно было разносить по отдельным docker-контейнерам с провязкой через docker-compose, но нам оказалось удобнее сделать общий базовый образ "все в одном".
Docker-образ конкретного сервиса наследуется от базового образа и получает всю необходимую инфраструктуру "из коробки". Такой подход позволяет нам унифицированно работать с 50+ сервисами и упрощает обновление инфраструктуры.
#инфраструктура
Forwarded from Яндекс
Media is too big
VIEW IN TELEGRAM
А ещё YaC 2023 — это мини-сериал из четырёх эпизодов. На Кинопоиске и YouTube.
Подписывайтесь 👉 @yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
Во время своей командировки пообщался с одним мудрым руководителем о методологии Agile и ее смысле. Это простое и понятное объяснение он узнал от консультанта, проводившего Agile-трансформацию в крупной российской компании.
Обычно объяснение методологии Agile сводится к перечислению идей и принципов из манифеста. Но основатели Agile заложили в методологию решение конкретной проблемы.
Итак, у нас есть команда, разрабатывающая разные и непохожие друг на друга проекты.
Для полноценного планирования проекта необходимо провести оценку задач, просчитать риски, нарисовать диаграмму Ганта и т.д. На этом бюрократическая часть не заканчивается, ведь нужно еще поддерживать построенную диаграмму Ганта и остальное описание проекта. Это много времени и сил.
Agile предлагает высвободить время по утомительному планированию и потратить его на улучшение продукта.
Тщательное планирование на начальном этапе исчезает, т.к. в нашем изменчивом мире технические требования также «плывут». Очень часто по мере движения IT-проекта всплывают сюрпризы, в корне меняющие сроки завершения проекта.
Но видение конечного результата, разумеется, никуда не девается. Помимо видения важно обзавестись измеримым показателем конечного результата и желаемым таргетом.
Далее этот измеримый показатель декомпозируется на несколько более гранулярных метрик.
Например, сервис хочет заработать больше денег на 30%. Декомпозируем метрику на две: вырастить аудиторию на 10% и повысить конверсию в рекламном продукте на 18%. Рост аудитории также можно декомпозировать по способу получения трафика: 2% через SEO, 3% через продуктовые запуски и 5% с помощью маркетинга.
Автономные команды со всеми нужными ресурсами работают над этими метриками и пытаются всеми силами достигнуть таргета. Как они будут достигать требуемых результатов — неважно. Дается полная свобода. Главное, чтобы метрика росла :)
Такой подход растит вовлеченность команд, творчество и в конечном итоге и общую эффективность системы.
И если изначальная "главная" метрика была выбрана верно, то Agile подход поможет добиться хороших результатов.
Все остальные рекомандации и практики Agile — вторичны и лишь облегчают ведение процесса:
— оценка в сторипоинтах — чтобы быстрее шипить то, что дешевле в разработке и дает бОльший эффект на метрику
— короткие спринты в разработке — чтобы быстрее увидеть прогресс по метрике
— ретроспективы — чтобы понять, почему метрика не растет
С учетом этих новых вводных методология Agile выглядит в другом свете. Agile-ритуалы воспринимаются не как бюрократия, а как фреймворк, помогающий улучшать твою метрику.
У адептов Agile нетцели дедлайна, есть только путь.
#менеджмент
Обычно объяснение методологии Agile сводится к перечислению идей и принципов из манифеста. Но основатели Agile заложили в методологию решение конкретной проблемы.
Итак, у нас есть команда, разрабатывающая разные и непохожие друг на друга проекты.
Для полноценного планирования проекта необходимо провести оценку задач, просчитать риски, нарисовать диаграмму Ганта и т.д. На этом бюрократическая часть не заканчивается, ведь нужно еще поддерживать построенную диаграмму Ганта и остальное описание проекта. Это много времени и сил.
Agile предлагает высвободить время по утомительному планированию и потратить его на улучшение продукта.
Тщательное планирование на начальном этапе исчезает, т.к. в нашем изменчивом мире технические требования также «плывут». Очень часто по мере движения IT-проекта всплывают сюрпризы, в корне меняющие сроки завершения проекта.
Но видение конечного результата, разумеется, никуда не девается. Помимо видения важно обзавестись измеримым показателем конечного результата и желаемым таргетом.
Далее этот измеримый показатель декомпозируется на несколько более гранулярных метрик.
Например, сервис хочет заработать больше денег на 30%. Декомпозируем метрику на две: вырастить аудиторию на 10% и повысить конверсию в рекламном продукте на 18%. Рост аудитории также можно декомпозировать по способу получения трафика: 2% через SEO, 3% через продуктовые запуски и 5% с помощью маркетинга.
Автономные команды со всеми нужными ресурсами работают над этими метриками и пытаются всеми силами достигнуть таргета. Как они будут достигать требуемых результатов — неважно. Дается полная свобода. Главное, чтобы метрика росла :)
Такой подход растит вовлеченность команд, творчество и в конечном итоге и общую эффективность системы.
И если изначальная "главная" метрика была выбрана верно, то Agile подход поможет добиться хороших результатов.
Все остальные рекомандации и практики Agile — вторичны и лишь облегчают ведение процесса:
— оценка в сторипоинтах — чтобы быстрее шипить то, что дешевле в разработке и дает бОльший эффект на метрику
— короткие спринты в разработке — чтобы быстрее увидеть прогресс по метрике
— ретроспективы — чтобы понять, почему метрика не растет
С учетом этих новых вводных методология Agile выглядит в другом свете. Agile-ритуалы воспринимаются не как бюрократия, а как фреймворк, помогающий улучшать твою метрику.
У адептов Agile нет
#менеджмент
Давненько не было баек о рабочих буднях. Исправляюсь!
Поздний вечер. Опенспейс. За рабочими местами осталось около 20-30 человек. Заходит в опенспейс один из моих сотрудников и удивляется, что до сих пор столько людей на работе.
Коллега решает нас немного развеселить и рассказывает забавную историю. Мы с интересом слушаем.
Потом немного меняется в лице и говорит:
— Только это секрет. Никому не рассказывайте!
Мы переглядываемся. Ведь секрет на 20 человек — больше не секрет.
Но тем не менее нам удалось сохранить эту тайну. А я, как рыбка Дори, быстро забыл в чем был секрет. Наверное, он до сих пор где-то в глубинах моих чертогов разума, но точно в безопасности :)
#байки
Поздний вечер. Опенспейс. За рабочими местами осталось около 20-30 человек. Заходит в опенспейс один из моих сотрудников и удивляется, что до сих пор столько людей на работе.
Коллега решает нас немного развеселить и рассказывает забавную историю. Мы с интересом слушаем.
Потом немного меняется в лице и говорит:
— Только это секрет. Никому не рассказывайте!
Мы переглядываемся. Ведь секрет на 20 человек — больше не секрет.
Но тем не менее нам удалось сохранить эту тайну. А я, как рыбка Дори, быстро забыл в чем был секрет. Наверное, он до сих пор где-то в глубинах моих чертогов разума, но точно в безопасности :)
#байки
Сегодня хочу рассказать про книгу Стивена Кови с попсовым названием "7 навыков высокоэффективных людей".
Семь навыков – не набор отдельных психологических приемов или формул. Это принципы для решения проблем и построения ценностей как в работе, так и в жизни.
В википедии можно прочитать классические формулировки, ниже приведу свою трактовку:
1. Проявляйте инициативу и не бойтесь брать на себя ответственность. Управляйте своей жизнью сами.
2. Сформулируйте образ и видение конечного результата. Это может быть definition of done у проекта или жизненная миссия. Только так вы придете в нужную точку в пространстве-времени.
3. Приоритезируйте задачи в соответствии с видением из пункта № 2. Матрица Эйзенхауэра вам в помощь и GTD, конечно.
4. Стремитесь к сотрудничеству, а не к соперничеству. Вместо поиска проигравшего фокусируйтесь на поиске решения, от которого все будут в плюсе.
5. Сначала стремитесь понять, потом – быть понятым. Слушать собеседника — это одно, а услышать и понять — совершенно другое. Истинные профессионалы должны уметь слышать.
6. Цените различия между людьми и уважайте их, совершенствуйте сильные стороны и компенсируйте слабые. Синергия дает ключи к новым возможностям и новым решениям.
7. Саморазвивайтесь во всех измерениях: физически, интеллектуально, социально и духовно. Человек — сложный механизм, и нужно планомерно развивать все "части" этого механизма.
Я читал эту книгу несколько раз и применяю эти принципы в жизни. Они могут показаться очень простыми и даже очевидными. Но тем не менее эти принципы помогают подняться на уровень выше и увидеть совершенно другое решение проблемы.
Альберт Эйнштейн заметил: «Те важные проблемы, с которыми мы сталкиваемся, не могут быть решены на том же уровне мышления, на котором мы находились, когда их создавали».
#книги
Семь навыков – не набор отдельных психологических приемов или формул. Это принципы для решения проблем и построения ценностей как в работе, так и в жизни.
В википедии можно прочитать классические формулировки, ниже приведу свою трактовку:
1. Проявляйте инициативу и не бойтесь брать на себя ответственность. Управляйте своей жизнью сами.
2. Сформулируйте образ и видение конечного результата. Это может быть definition of done у проекта или жизненная миссия. Только так вы придете в нужную точку в пространстве-времени.
3. Приоритезируйте задачи в соответствии с видением из пункта № 2. Матрица Эйзенхауэра вам в помощь и GTD, конечно.
4. Стремитесь к сотрудничеству, а не к соперничеству. Вместо поиска проигравшего фокусируйтесь на поиске решения, от которого все будут в плюсе.
5. Сначала стремитесь понять, потом – быть понятым. Слушать собеседника — это одно, а услышать и понять — совершенно другое. Истинные профессионалы должны уметь слышать.
6. Цените различия между людьми и уважайте их, совершенствуйте сильные стороны и компенсируйте слабые. Синергия дает ключи к новым возможностям и новым решениям.
7. Саморазвивайтесь во всех измерениях: физически, интеллектуально, социально и духовно. Человек — сложный механизм, и нужно планомерно развивать все "части" этого механизма.
Я читал эту книгу несколько раз и применяю эти принципы в жизни. Они могут показаться очень простыми и даже очевидными. Но тем не менее эти принципы помогают подняться на уровень выше и увидеть совершенно другое решение проблемы.
Альберт Эйнштейн заметил: «Те важные проблемы, с которыми мы сталкиваемся, не могут быть решены на том же уровне мышления, на котором мы находились, когда их создавали».
#книги
Когда я стал руководителем отдела, то первое, что я сделал — пошел за советами к более опытным коллегам.
Один из руководителей дал мне такой совет: "Не переставай программировать". Руководитель группы не перестает программировать и порой не уступает в количестве коммитов своим сотрудникам.
Чем выше поднимаешься по административной иерархии, тем больше времени "жрут" различные руководительские активности. На программирование остается все меньше и меньше времени. Есть соблазн забросить программирование и сосредоточиться на управлении людьми.
Но в этом случае руководитель начинает отрываться от реальных проблем и запросов настоящих разработчиков. Это влияет на принимаемое решение.
Именно поэтому я продолжаю решать небольшие и несрочные задачки.
Думаю, что на картинке выше вы без труда найдете мою карту коммитов. Но с ходу непонятно, какая карта коммитов принадлежит разработчику, а какая — руководителю группы.
#руководство
Один из руководителей дал мне такой совет: "Не переставай программировать". Руководитель группы не перестает программировать и порой не уступает в количестве коммитов своим сотрудникам.
Чем выше поднимаешься по административной иерархии, тем больше времени "жрут" различные руководительские активности. На программирование остается все меньше и меньше времени. Есть соблазн забросить программирование и сосредоточиться на управлении людьми.
Но в этом случае руководитель начинает отрываться от реальных проблем и запросов настоящих разработчиков. Это влияет на принимаемое решение.
Именно поэтому я продолжаю решать небольшие и несрочные задачки.
Думаю, что на картинке выше вы без труда найдете мою карту коммитов. Но с ходу непонятно, какая карта коммитов принадлежит разработчику, а какая — руководителю группы.
#руководство