Жаль, что в цифровом веке всё ещё нельзя отказаться от бумажных документов — увы, суды сканы документами не считают. Однако это не означает, что бумажную документацию не нужно оцифровывать.

Данный кейс полностью решает проблему: «А в какой папке лежит этот блджадский договор, не помню когда заключённый с Иваном Никифоровым?».

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

Поступил документ — берём этикетку с номером, присобачиваем к первой странице. Если документ многостраничный, расшиваем, сканим на хорошей МФУшке, тут же делаем pdf и кидаем в эвернот.

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

По привычке пишу «экселевский», но лучше использовать гуглодокументы — там удобнее организована совместная работа.

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

Крайне желательно иметь премиум аккаунт, чтобы этот процесс могли осуществлять несколько человек.

Естественно, раз в неделю соблюдение правил работы с входящей документацией должен проверять какой-нибудь супервайзер.

Руководитель небольшой компании (до 30 человек) должен хотя бы раз в две недели устраивать короткие (до 10 минут) встречи с каждым сотрудником. Причём, эти встречи не должны быть посвящены отчётности (Что делал? Что сделал? Что делаешь?), а проходить в свободной форме (Какие есть идеи? Что можно улучшить? Что думаешь насчёт всего?).

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

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

И ещё один момент. Такие встречи не должны быть неожиданными. Лучше назначить заранее, чтобы сотрудник успел подготовиться.

Искренне жаль, что многие руководители об этом забывают.

Человек, желающий стать сильным менеджером, должен играть в компьютерные игры. Причём, речь не о «Косынке» и не о злых птичках, а о серьёзных MMORPG.

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

В MMORPG не существует такого понятия как «проблема». Любой квест, даже самый сложный (в качестве примера можно привести цепочку WOW квестов на получение легендарного топора «Тёмная Скорбь». Для того, чтобы справиться с этой цепочкой, нужна работа целой гильдии в течение нескольких недель, однако владельцы «Тёмной Скорби» существуют, хоть и в небольшом количестве), является лишь задачей, которую можно решить. Для этого может потребоваться потратить время на прокачку персонажа, разжиться дополнительными ресурсами, привлечь партнёров по гильдии или случайных попутчиков, но решить его можно всегда. Формирование такого мировоззрения крайне полезно — в работе можно столкнуться с огромной и страшной проблемой, но её можно разрешить, если воспринимать как квест.

Это не единственная «плюшка», которую можно получить от игры. Есть частности, бесполезные на первый взгляд, но дающие глубокое понимание верных методов поведения. К примеру, хардкорные игроки в WOW тратят много времени на распределение талантов. Есть ограниченное количество очков талантов, которые нужно распределить по трём веткам в любых комбинациях. Момент, когда игрок понимает, что распределив таланты иначе, он может усилить лечение/урон/выживаемость является точкой осознания того, что для достижения эффективных результатов совершенно необязательно тратить больше ресурсов, важна сбалансированность и сфокусированность в пределах имеющихся ресурсов.

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

Об умении успешно координировать рейды, на мой взгляд, можно писать в резюме. Тут и менеджмент ресурсов и умение мотивировать, и конфликт-менеджмент, и рекрутинг, и всё на свете.

Словом, играйте и не считайте это время потерянным.

1

Error happened.

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

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

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

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

Я верю, что есть гении, которым всё это не нужно и которые способны, скажем, взять и написать гениальный код. Самообразование, природные способности и всё такое. Однако реалии производства таковы, что основную ценность имеют те, кто способен постоянно писать не гениальный, а работающий код. Восемь часов в день, сорок в неделю. А сложные и интересные задачи бывают не всегда. Бывает необходимость и пару значений в сотне документов скриптом поменять, и простую табличку с процедурой заполнения запилить, и пару показателей в отчёт добавить. И при этом нельзя говорить, что скучно, неинтересно или просто влом. Нужно взять и сделать. Будет ли справляться человек, которому было влом сидеть на парах в ВУЗе? Не уверен.

90 % работы для программиста — это корпоративное ПО

Основы экономики: цена чего-угодно (включая вас) — это функция спроса и предложения. Давайте сначала посмотрим на спрос. Большинство ПО не продается в коробках и не доступно для скачивания в интернете или App Store. Большинство ПО — это тоскливые узкоспециальные корпоративные приложения, поддерживающие глобальную экономику со всех вообразимых сторон. Эти приложения подсчитывают издержки, оптимизируют расходы на пересылку, помогают составлять бухгалтерские отчеты, проектировать новые интерфейсы, вычислять цену страховки, помечать подозрительные заказы для ручной проверки и т.д. ПО решает проблемы бизнеса.

ПО решает проблемы бизнеса несмотря на свою душераздирающую скучность и отсутствие технологической сложности. Например, представьте себе электронную форму отчета о командировочых расходах. Для компании размером в 2000 человек она может сэкономить порядка 5000 человеко-часов в год в сравнении с ручной обработкой бумаг, что при средней стоимости часа работы в 50 $ сэкономит 250 000 $. Компании все равно, что это самое примитивное на свете CRUD-приложение. Единственное, что имеет значение, это то, что оно сокращает издержки или генерирует прибыль.

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

«Перестаньте называть себя программистом и другие карьерные советы»

Другое дело, что наличие диплома ничего не гарантирует. К счастью, это не проблема — опытный наставник выявит истинный уровень (и соответствие другим важным критериям) ещё на собеседовании. К сожалению, в последнее время появилось много «специалистов по прохождению собеседований». Тут сложнее, но истинный уровень всплывает во время испытательного. Суть в том, что отсутствие хоть какого-нибудь диплома должно тут же послужить красной лампочкой — может быть, не стоит тратить на этого человека время и ресурсы?

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

И ещё один момент. Если мы говорим о человеке, который, не имея корочек, уже проработал хотя бы два года на аналогичной позиции в другой компании, разговор другой.

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

• Слишком много активных чатов. Лишь некоторые из них действительно полезны, в остальные достаточно изредка заглядывать, но уведомления утомляют.
• Трудно найти старый групповой чат, в котором была достигнута какая-то договорённость.
• Контакт-лист становится реально огромным.
• Даже в рамках хистори одной переписки трудно найти нужное место.
• Некоторые люди очень долго не отвечают.
• Некоторые сотрудники используют вместо фотографий изображения котов, енотов, гербов, хохлов. По фамилии человека не всегда можно опознать, приходится несколько секунд гадать, из какого отдела этот кот или енот.

Полезные советы:

• Выучите команды /alertsoff и /alertson. Первая выключает уведомления о новых сообщениях в данном чате, вторая включает. Требуется на случай, когда обязательно нужно висеть в каком-то чате, чтобы видеть инфу по необходимости, но реагировать не нужно.
• Создаёте групповой чат — сразу же присваивайте ему имя, соответствующее теме беседы. Я ещё и картинку присобачиваю, но это лишнее. Тема закрыта — архивируйте переписку и удаляйте чат. Если в контакт-листе есть неперименованные чаты — удаляйте.
• Все имена контактов должны быть в едином стиле. Лучше всего — Фамилия Имя. Также нужно добавлять к имени короткий тег, например #market, #admin или #coder на своё усмотрение. Очень сильно облегчает узнавание человека, с которым общаетесь редко.
• В скайпе есть странные стандартные смайлики неясного назначения, например, звёздочка. Так вот, их назначение — маркировка важного момента в длинной переписке. Например, достигли договорённости — сформулируйте её ещё раз и поставьте в начале фразы звёздочку — потом будет легко отыскать.
• Если есть возможность не писать текстом, а позвонить войсом — звоните. Если есть возможность видеосвязи, демонстрации экрана — обязательно пользуйтесь.
• Если во время голосового обсуждения достигли какой-либо договорённости, немедленно дублируйте её текстовой строкой в чате. По правилам делового общения, после такого обсуждения организатор высылает участникам резюме встречи, если дублировать устные договорённости текстом по мере разговора, это сильно ускорит написание резюме.
• В чате были написаны некие важные данные — немедленно дублируйте их в основную систему хранения информации (эвернот, закладки браузера, таск менеджер, что угодно). Не забывайте, что хистори в скайпе синхронизируется через задницу, при установке скайпа хистори нужно копировать руками. И вообще, присмотритесь к Viber — перспективная штука.
• Я вас умоляю, используйте в качестве аватара свою фотографию, причём в виде лицевого портрета без головного убора. Хотя бы для служебного акканута — в личном может быть всё, что угодно. Имеете что-то против — разместите логотип компании, но не зайчиков, котиков, анимешных персонажей и прочей ерунды. Во-первых, это совершенно неуместно, а во-вторых, ухудшает узнаваемость.

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

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

Результат:

1. Менеджер не владеет точной информацией о текущей загрузке разработчиков и не может нормально планировать.
2. Разработчиков часто дёргают, не дают уйти в поток.
3. Внедренцы конфликтуют из-за разработчиков.
4. В первую очередь делают запросы тех, кто «громче кричит», а не те, которые стратегически более важны.
5. Сроки срываются, очередь копится, организация теряет деньги, клиенты нервничают.

 
 
Приведённый ниже подход снижает скорость, но повышает предсказуемость разработки:

Между внедренцами и менеджером появляется очередь. Внедренцы добавляют свои запросы в очередь. Менеджер берёт запросы в работу в порядке очереди. В исключительном случае внедренцы обращаются к менеджеру для решения срочных вопросов. Напрямую к разработчикам никто не лезет. За очередью наблюдает директор по развитию или генеральный директор компании.

Подробнее о работе с очередями можно прочитать в посте «Об очередях».

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

Традиционный для отечественных компаний сценарий, ведущий к подобным проблемам:

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

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

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

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

Финиш. В продукте бардак.

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

Данный рецепт холостяцкой кухни чрезвычайно прост, а продукт на выходе — нажорист и красив.

Понадобятся:

1. Любые макароны.
2. Сливки.
3. Бекон.
4. Помидоры.
5. Лук.
6. Специи по вкусу.

Первые три компонента критичны, остальные опциональны. Бекон можно заменить грибами, а лук чесноком.

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

Пока макароны варятся, ставим на малый огонь сковороду, льём туда немного растительного масла (немного!) и греем. Шинкуем бекон и помидоры, режем кольцами лук. Как только сковорода немного прогреется, выкладываем на неё то, что получилось нашинковать. Обжариваем до золотистой корочки. Как только станет шипеть совсем уж сильно (через три-четыре минуты обжаривания), заливаем сливками.

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

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

Как только содержимое сковородки дойдёт до кондиции, выливаем его на макароны. Затем можно насыпать тёртого сыру и подать к столу.

Бонус. Приведённым в данном рецепте «соусом» можно залить не только макароны, но и рис — получается не менее вкусное блюдо.

Всегда можно повысить продуктивность при помощи искусственных ограничений. Вот несколько кейсов.

Избавляемся от ненужных вещей.

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

Испытано — выкинутый хлам НИКОГДА не пригождается. Я переехал в новую квартиру из старой, десятилетиями заполняемой разнообразными вещами и взял с собой лишь те вещи, которые реально использую и их крайне мало.
 
 
============================

Закладки в браузере.

Для хранения закладок используйте ИСКЛЮЧИТЕЛЬНО панель Chrome. Туда влезает 10-12 сайтов. Хотите поставить новую, сверх лимита — придётся удалить одну старую. Если ссылка реально может пригодиться в будущем, кидайте в соответствующий блокнот эвернота, но в браузере не держите.

Испытано — 16 кнопок спид диала хватает вообще на всё, причём три-четыре пустуют. После перехода на мак, стал пользоваться панелью Safari и её же спид диалом. Ограничения работают.
 
 
Моя панель выглядит так:

 
Двух-трёх букв достаточно для идентификации сервиса.

• FD — RSS-ридер Feedly.
• BB — интернет-банк.
• GK — Google Calendar.
• EN — веб версия Evernote.
• GD — GoogleDoc
• GM — GoogleMaps
• TJ — Tjournal, весьма интересный ресурс.
• PB — Пикабу, убийца времени.
• Mtr — Метрополь, ещё один убийца времени.
• TG — Веб версия Телеграма.
• ВК — Вконтакте.
• GA — GoogleAnalytics
• ПОПСА — этот самый блог.
• GTr — гугловый переводчик.

 
 
============================

Лишний софт.

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

Испытано — я больше не боюсь кражи/выхода из строя ни ноутбуков, ни ПК и готов развернуть рабочее окружение за пятнадцать минут. Позже запилю пост об используемом ПО на работе и дома.
 
 
============================

Безбумажность.

Если у вас скапливается много бумаги, заведите папочку и ограничьте её объём 30 листами. Всё остальное мужественно сканируем, конвертируем, проставляем теги и с огромным наслаждением пропускаем бумажные версии через шрёдер. Папочка работает так же, как и коробка для хлама: хотите положить листик — должны выкинуть два имеющихся.

Не пробовал — у меня мало бумаги.

Ещё не раз и не два я напишу о ментальных картах. Это универсальный инструмент.

Конспектируем лекцию/совещание/что угодно при помощи ментальной карты.

Плюсы:
Читать потом в сто раз проще, чем линейный конспект.

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

==============
В качестве примера приведён конспект занятия клуба Agile-практиков. Тема, как видите — заказная разработка по скраму.

1. Лучше всего использовать большой лист. А4 недостаточно — посмотрите, как приходится мельчить.
2. Обязательно нужно рисовать картинки — они вызывают нужные образы быстрее, чем текстовые надписи.
3. Очень важно рисовать разными цветами, эта схема в ч/б, потому что не было под рукой цветных ручек.