Работать эффективнее

Работать эффективнее

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

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

2. Если письмо не требует ответа или какой-то реакции, отправляйте его в архив. Пустая папка «Входящие» — это прекрасно. Используйте inbox в качестве списка To Do.

3. Не используйте одновременно несколько программ/приложений. Закончили с соцсетями — закройте окно. Проверили почту — закройте ее. Не нужно серфить в интернете — закройте браузер. Даже фоном ничего не оставляйте. Несколько задач одновременно отвлекают и мешают сконцентрироваться на чем-то одном. (далее…)

12 правил плохого менеджера

12 правил плохого менеджера

Никогда не планируйте

Проект, как правило, делается сам собой, вырастает, как дерево: главное — вовремя посадить семена и удобрить почву. Разве вы когда-нибудь встречали чудака, который будет прикидывать, насколько вырастет за год дерево, которое он посадил? Правда в том, что планирование никогда еще никому не помогло сделать хороший проект. Точные сроки — это лишняя ответственность и ненужная головная боль. Диаграммы Ганта — для слабаков. Забудьте о них.

(далее…)

А почему бы не перестать страдать по мелочам?

А почему бы не перестать страдать по мелочам?

Вот ждёте вы важное письмо от коллеги. 5 минут, 10, 20 — а нет его! Блин, а проверю-ка я спам. И точно — есть, 19 минут назад пришло. Чёрт, я же вроде уже добавлял этого человека в whitelist — почему письмо в спаме? Надо разобраться, проверить правила… Но сейчас нет времени, это мелочь, письмо срочное, а в эти правила как закопаешься, так на полчаса, еще и админов может быть придётся дёргать. Нет, потом…
А завтра письмо от коллеги опять в спаме.

Так, заходим на сайт… Блин, не сохранилась авторизация. Вот на всех сайтах сохраняется, а тут нет. Почему? Может быть почистить куки? Может сохранился старый пароль? Надо разобраться… Нет, ну это сейчас и в настройках рыться, и не дай бог, сохранённые пароли для других сервисов потру, нет, потом. Это ведь, в сущности, мелочь, а мне надо работать…
А завтра снова раздражение от не сохранённой авторизации и минута на размышление о причинах.

О, вот библиотека, которая делает то, что мне надо. Хм, на Python, а мне надо на С++. А на С++ такой нет. Ну ок, почитаю питоновский код, пойму общую идею и перепишу на С++. Ух ты, у моего редактора нет подсветки кода на Python! Может быть есть какой-то плагин? Или поискать другие редакторы? Ай, ну ладно, это ведь одноразовая задача, не буду тратить время — сейчас полдня потрачу на сравнение десятка IDE и редакторов кода на Python, а у меня ведь задача совсем другая, плюну, это ведь мелочь…
А завтра к библиотеке на Python выходит обновление и его снова приходится читать.

Почему бы не перестать страдать по мелочам?
(далее…)

MVP – не дешевый продукт, а умный процесс познания

MVP – не дешевый продукт, а умный процесс познания Минимально жизнеспособный продукт (minimum viable product — MVP) – не всегда уменьшенная/удешевленная версия законченного продукта. Определение точки, в которой можно выпустить MVP, с самого старта может сэкономить вам много времени, денег и ваших слез.

Дроны в Хартленде

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

С гвоздем в глазу все видится гвоздем

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

Заполучив что-то вроде нового супермасштабируемого молотка, горячо обсуждаемого на Hacker News, вы лупите им по всему, что попадается на вашем пути, пока каждая ваша вещь не превратится в пыль, а все, кого вы любите, не скончаются от тяжелых черепно-мозговых травм.

Переведено в Alconost Translations.

С гвоздем в глазу все видится гвоздем

(далее…)

Создаем резюме на LaTeX — как и зачем?

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

(далее…)

Правило программиста #1: оставьте эмоции дома!

Как программисты, мы гордимся нашей работой. Мы показываем эту гордость, выполняя наши задачи лучшим образом. Мы относимся к ним со всей дотошностью, вплоть да названий переменных и методов. Мы всегда выбираем нужные классы для конкретной задачи, не смотря на то, что пользователю все равно, использовали ли мы List<KeyValuePair<Guid, string>> или Dictionary<Guid, string>. Мы нервно стараемся довести все до идеального состояния. Многие даже могут подумать, что у нас ОКР.

Но что происходит, когда разработчик слишком гордится тем, что он или она написали?

Что, если из-за этого эмоции проникают в код? Что может случиться, если программист не может расстаться не только с его или ее кодом, но и с методами ведения работы, принятия решений и своим поведением, как разработчика? (далее…)

Жизнь управленца, кадр 1, не надейтесь на понимание

95% своей сознательной жизни я связан с ИТ, начав как переводчик, достаточно быстро перешел в ИТ, развитие проектов, в общем кто плавал, тот поймет.

Основная проблема, с которой я столкнулся, во время своего путешествия, это конечно люди. Не плохие люди и не хорошие, а просто люди-сотрудники.

Так вот, в любой нормальной ИТ компании, которая занимается программерством, 90% это программисты процентов 7% технари, остальное административный отдел. Самые простые люди в компании это конечно администраторы, в прямом смысле этого слова, те люди кто делают чай, кофе, чистоту, учет и безопасность. И так часто происходит что именно эти люди самые бесправные, вы знаете что их легко заменить, их никто не замечает и тд и тп.
(далее…)

Стратегия продукта подразумевает ответ — «Нет!»

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

Стратегия продукта подразумевает ответ — «Нет!»

Как следует из последней рекламы Apple, могут существовать десятки тысяч версий вашего продукта, которые могут появляться из-за разных фич, важных и неважных. Большинство из этих версий с треском провалятся и только лучшие смогут обслужить рынок. (далее…)

Детальное описание действий IT-отдела — базовый набор документации

Во многих западных странах IT-аутсорсинг регулируется либо отраслевыми стандартами, либо вообще на госуровне. У нас такого нет. Поэтому за несколько лет был собран документ, который детально определяет термины в IT-аутсорсинге и расписывает, что в какой тип работ конкретно входит. С его помощью мы документируем работы, а потом чётко и прозрачно считаем, что сколько стоит.

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

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