О необъятности книг

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

Сегодня видел фотографии книжных полок какой-то стокгольмской библиотеки (пик). То есть, ведь в каждой стране есть огромное количество книг на национальном языке. Это тяжело даже в принципе, осмыслить.

Яндекс говорит, что в мире в данный момент 129 864 880 книг. Я предпочитаю слушать, а не читать, и комфортно слушаю 2 книги в месяц. Значит, чтобы их прослушать, мне нужно 5 411 036,6 лет. По сравнению с возрастом Земли (4,54 миллиарда лет) не очень долго, но дело в том, что пока я буду слушать 24 книги в год, в мире за этот год будет выходить ещё 1 млн. новых книг.

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

Такие дела.

* * *

Кто о чём, а я про ё.

Афера. Слово из фр. affaire – дело. Произносится через букву Е. Никаких Ё тут нет.

Платёжеспособный. А вот здесь Ё нужна. Вся суть в том, что в слове есть основное ударение и побочное, которое как раз падает на букву Ё.

Истекший – истёкший. А в этом случае нужно смотреть на смысл. Если мы говорим о жидкости (истёкший кровью), то нужна буква Ё. Если же про время (истекший год), то нужна буква Е.

А ещё, букву ё обязательно нужно писать в новых словах. Например, вы знаете, что тверк на самом деле твёрк, а ЧВК Редан на самом деле Рёдан? История сама примет решение о значимости этих явлений, но пока эти слова новые, ё лучше не игнорить.

* * *

О финансовой дисциплине

Финансовая дисциплина и домашняя бухгалтерия не сделают вас новыми Безосами сами по себе, но они помогут оптимизировать затраты, сформировать запас денег на тяжёлые времена, а также выделить суммы, которые можно безопасно инвестировать.

Но мешает мышление. Когда-то давно я курил, но не покупал пачку каждый день в магазине, а раз в два с половиной-три месяца приезжал в оптовый магазин и брал сразу 10 блоков. И один мой друг никак не мог этого понять. Я объясняю, во-первых, оптом процентов на десять дешевле. Во-вторых, у тебя нет проблемы закончившихся в ночи сигарет. Ты просто достаёшь пачки из блоков, заначенных в шкафу и куришь. Сигареты не портятся, держать в холодильнике их не нужно. Чистая экономия и оптимизация.

А он говорит, как же так, единовременно отдать за сигареты 6-8 тысяч, да, после этого не будет проблем с сигаретами, зато появятся проблемы с деньгами.

Учёт доходов и расходов помогает сломать это мышление и начать оптимизировать затраты. Но в итоге это закончилось это тем, что мы оба бросили курить. Я вообще (3 года, 8 месяцев и 22 дня ни одной сигареты), он перешёл на кальян, что тоже несколько дешевле.

* * *

О старинном кеке

Слово «кекнуть» тогда означало «икнуть». Ничто не ново.

* * *

Об ушедшем счастье

Нашёл картинку и загрустил. В 2009 году я уже закончил универ и год как страдал фигнёй в роли фотографа агентства развлечений, взаимодействие с которым закончилось с кризисом конца 2008, когда гражданам стало не то, что не до развлечений, но на фотографе стали экономить.

Благодаря успешно сделанному тестовому, получил работу в геймдев-компании «Айгринд», снял квартиру в конце проспекта Мира, купил небольшой нетбук и радовался жизни. Нашёл подработку юзабилити-аудитором, где зарабатывал на излишества. А почему бы не заработать? Доллар чуть дороже 30 рублей, ни с кем не воюем, слово «санкции» ещё даже не звучало в публичном поле. Хороший ужин в ресторане, алкоголь без ограничений и счёт редко превышает 1000 рублей.

Калининградский продавец стиральных машин Алексей Беба бросает продажи и создаёт театральную студию «Эволюция», я начинаю туда ходить и учусь у отличных актёров Елены Мочаловой и Антона Арнтгольца. Занятия проходят в банкетном зале ресторана «Ольштын» поздно вечером, часто не удаётся попасть на автобус или маршрутку до съёмной квартиры, Яндекс Такси ещё не придумали. Через раз совершаю длинную прогулку через весь Калининград. Зима, но не грязно.

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

Выходит «Сталкер. Зов Припяти». До биткоин-истерии ещё долго, видеокарты стоят вполне вменяемых денег. Выходит отличный кооп «Left for dead 2», в который мы с друзьями играем до сих пор.

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

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

* * *

О трёх числах

В самом начале карьеры (примерно весна 2009 года) меня пригласили на собеседование на сисадмина в одну строительную компанию. И на собеседовании гендир сказал: «Назови, пожалуйста, три числа. Минимальную зарплату, за которую ты готов согласиться работать. Комфортную зарплату. И зарплату, с которой ты сможешь позволить себе излишества».
Я, совершенно не понимая подвоха, назвал 15 тыс., 25 тыс. и 40 тыс.

Через несколько дней мне позвонили и сказали, что приглашают на испытательный. Я стал ездить к ним в офис, познакомился с предыдущим сисадмином (он продолжал оказывать этой компании услуги как ИП), стал настраивать всякое, помогать пользователям. Ну и дня через три решил спросить у гендира (договора мы не заключали), а какая у меня зарплата? А он и ответил: «15 тыс., ты же сам назвал эту сумму».

С тех пор я перестал отвечать на вопрос про три числа честно.

* * *

О любимых приложениях

У каждой профессии своё «любимое» приложение. В кавычках потому, что любимое оно не по причине нежных чувств, а от частого использования. Если вы большую часть времени видите на экранах людей эксель, значит это финансисты или бухгалтера. Если ворд — техписы или юристы. Редакторы презентаций жалует начальство. На экранах программистов разнообразнейшие IDE. UX/UI сидят в Figma.

А вот на экране пиэма чаще всего вы можете наблюдать мессенджер или почтовый клиент.

* * *

О подрыве и совершенствовании командного духа

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

* * *

О договорённостях в скраме

При классическом скраме команда обменивает гарантию выполнения целей спринта в обмен на невмешательство в скоуп спринта в процессе. Короткие итерации (2-3 недели) делают этот обмен вполне реальным.

То есть, команда реализует всё, что напланировано, но руководство в лице продакта и стейкхолдеров не вкидывают новых задач в спринт и не меняют постановку взятых задач.

Если ваше руководство не может сохранять фокус 2-3 недели и это происходит регулярно, у компании проблема.

* * *

О декриминализации ошибок и эскалаций

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

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

* * *

Об эйджизме

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

Я помню, как в детстве говорил отцу: «Папа, я набрал в Флинстоунах стопицот очков! Папа, я обыграл компьютер на чемпионате мира по футболу! Папа, я построил самый прибыльный парк развлечений!» И он всегда мне на это отвечал: «Ну и где в реальности твои стопицот очков, кубок мира и парк развлечений? Нет у тебя ничего.»

А виртуальные вещи так же ценны как и реальные. Броня T1 из Варкрафта так же полезна как кожаная куртка с меховой оторочкой в реальности. Аккаунт в Линкадине с SSI 75 или инстаграм с миллионом подписчиков так же ценен как крутые записи в трудовой книжке.

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

* * *

Об источнике для нейросетевой копии

Потихоньку материализуется эпизод Чёрного Зеркала «Сейчас вернусь» (2 сезон, эпизод 1), в котором девушка при помощи нейросетей возвращает погибшего мужа, сначала в виде переписки, потом в виде голоса, а потом и в виде болванчика.

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

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

* * *

Об увольнениях

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

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

И ещё важный момент. Надо обязательно, хоть и без лишних подробностей, пояснить команде, почему Васю попросили написать заявление. Предъявлять им список васиных косяков не надо, достаточно передать суть. Например: «Васины задачи возвращались на доработку тестировщиками запредельно много (десятки) раз». Это предупредит ненужные разговоры и слухи.

* * *

О скорости онбординга и музыке

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

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

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

К сути. Некоторые новички могут проходить онбординг в вашей компании дольше других. Дольше разбираться в регламентах, хитросплетениях отношений отделов, не с первого раза правильно делать регулярные отчёты, тупить с джирой (её каждая компания настраивает под себя и какие-то время надо привыкать). Это не означает, что эти новички хуже других или что будут хуже вести реальные проекты или что их онбординг в целом, займёт больше времени. Разберутся за положенные три месяца и нервничать по этому поводу не надо. Это такая особенность мышления, которая не является ни положительной, ни отрицательной чертой.

Людей вообще, нельзя сравнивать друг с другом, это некорректно.

* * *

О простых доработках в клиентском сервисе

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

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

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

* * *

О ватных палочках

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

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

* * *

Шаблон для встреч один на один

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

* * *

О непечатных символах в гуглодоках

В гуглодоках добавили возможность показать непечатные символы. Контрол или комманд шифт P, либо Вид → Показать непечатные символы. Может, надо кому.

* * *

Об умении сдаться

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

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

Умение сдаться — тоже важный навык.

* * *

О промдизайне

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

Долго думал. Могут ли в нашей стране появиться такие люди как Джобс и Айв и создать настолько крутые и революционные продукты? Предположим, родился бы в РФ условный Евгений Айвазов в семье специалиста по изделиям из серебра, который привил бы ему с детства любовь к дизайну. И был у него такой же талант к промдизайну и такая же страсть к этому делу.

Нашёлся бы в РФ университет, подобный Нортумбрии, в котором бы дизайн преподавался настолько же серьёзно? И главный вопрос, могла бы в РФ случиться история, в которой Евгений пришёл бы в компанию, занимающуюся промышленным дизайном, поставил там станок с ЧПУ и стал делать по сто пятьдесят прототипов внешнего вида устройства, пока не достигнет совершенства? Думаю, ему сказали бы, идите, Евгений, лесом. Мы импортируем ублюдочные, но дешёвые девайсы из Китая и продаём втридорога, таков путь.

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

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

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

В сети есть огромное количество материалов о том, как правильно проходить собеседования на менеджера проектов, но мало кто пишет, как собеседования проводить. На что обращать внимание? Какие вопросы задавать? Как интерпретировать ответы?

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

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

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

Поинтересуйтесь, как у кандидата дела с поиском работы, много ли собеседований, есть ли уже какие-то конкретные варианты, можно без подробностей.

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

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

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

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

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

Совет. Спрашивайте не «как вы это делали?», а «как вы это делали и как по-вашему это правильно делать?» Вторая форма вопроса более ценна, потому что менеджер мог неправильно действовать по указанию начальства, чтобы не потерять работу, при этом прекрасно зная, как правильно.

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

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

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

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

Поинтересуйтесь, как скоро кандидат сможет выйти на работу, если получит оффер.

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

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

Так как сделать, чтобы ключевые сотрудники не уходили как можно дольше?

Культура

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

Есть мнение, что деньги — главное. Достаточно платить чуть выше рынка и всё будет хорошо. Это не совсем так.

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

Видение будущего

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

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

В общем, если уделять внимание этим двум аспектам, люди будут работать на вас дольше, чем в среднем по больнице. Не вечно, конечно, есть вещи вне контура вашего влияния, но долго.

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

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

* * *

1. Исследовать, как на популярных сайтах и сервисах реализованы механизмы добавления контента в Избранное (Favorites). Рассмотреть процесс не с технической точки зрения, а с точки зрения удобства для пользователя.
2. По результатам исследования подготовить краткий отчет о текущих тенденциях в процессе добавления контента в Избранное (Favorites). В отчете привести ссылки, скриншоты и краткие характеристики с точки зрения usability для каждого рассматриваемого сайта.
3. Выбрать из проанализированных методов добавления контента в Избранное самый простой и удобный с точки зрения пользователя, обосновать выбор. Описать, как работает выбранный механизм в виде краткого описания всего процесса: что видит пользователь, какое поведение при добавлении в Избранное, при удалении из избранного, дополнительные подсказки, которые получает пользователь в данном процессе.

* * *

Вам нужно оценить проект, предполагающий как верстку, так и JS-программирование. Часть проекта уже реализована не в CSSSR, как вы будете действовать, чтобы учесть и минимизировать риски при оценке трудозатрат?

Наш заказчик — производитель воздушных шаров — готовит выставочный стенд. Частью стенда предполагается сделать HD-телевизор, чтобы демонстрировать на нём презентацию компании.

PR-директор заказчика обратился к нам с просьбой сверстать презентацию под нативный браузер этого телевизора.
А. Какие риски в реализации этого проекта вы видите?
Б. Предложите, как минимизировать риски.

Умение задавать правильные (исследовательские) вопросы, и последовательно добиваться четких, однозначных ответов — ключевой навык менеджера.
Взгляните на этот UI-kit (ссылка протухла). Сформулируйте список вопросов, ответы на которые помогут вам оценить трудозатраты по вёрстке и JS-программированию.Учитывайте, что тот, кто будет на них отвечать может и не обладать техническими познаниями в веб-разработке.

* * *

Оцените трудозатраты по вёрстке и JS-программированию этого UI-kit (ссылка протухла). Представьте, что вы уже получили ответы на все уточняющие вопросы из предыдущего задания. Закладывайте в оценку самый трудоемкий вариант. Составьте эстимейт в этом же файле, по шаблону приведенному ниже. Требования кроссбраузерности ограничиваются только самыми последними десктопными версиями Chrome, FireFox, Opera, Safari, IE.

Оценка сильно зависит от скиллов исполнителя. Берём «сферических верстальщика и джависта в вакууме»

* * *

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

* * *

Вы получили следующее ТЗ от заказчика для разработки web ПО: «Необходимо сделать кнопку, при нажатии на которую начинается салют». Составьте список уточняющих вопросов, которые Вы бы ему задали при обсуждении.

* * *

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

Задача — описать систему управления электронной очередью посетителей, нуждающихся в описанных выше услугах.

Есть три основные роли — посетитель, менеджер и старший смены.

* * *

Звонит заказчик. Он рассержен создавшейся ситуацией. Из разговора вы понимаете, что проблема заключается в том, что когда он вбивает в поисковую строку яндекса свой сайт, то видит в результатах выдачи сообщение: “Возможно, ваш сайт заражен вирусом, не рекомендуем переходить на него во избежание заражения…” Что вы ответите клиенту? Опишите пошагово свои действия. Проанализируйте и укажите, сроки выполнения задачи.

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

Вы работаете на должности аккаунт-менеджера. Одному из Ваших проектов требуется установить Google analytics. Вам нужно делегировать задачу или часть задачи вебмастеру. Ваши действия/ТЗ/Этапы?

* * *

Вводная: Представь, что твоей команде (5-7 человек) пришлось на неделю прервать работу над проектом (например, задерживается серверная разработка заказчика c API, тянут со стартом оплаты бухи или компонент, от которого вы зависите от других отделов).

Задача: Как ты построишь работу команды на этой неделе?

Вводная: Внутренний заказчик (в холдинге) сформулировал требования так: мне нужен проект к событию ЧМ-2018. Он может быть фановым мобильным приложением или игрофикационным, но важно прокатиться на этой волне и заработать денег. И это все требования которые он выставил.

Задача: Опиши твой алгоритм действий, декомпозицию оценки стоимости разработки проекта, 1-2 компонента/пользовательской роли для ТЗ (как раз важно будет понять, по какой структуре ты их готовить умеешь), и скоуп для первого спринта команды разработки.

* * *

Каким образом вы будете выявлять проблемные ситуации и возможности их решения на своей новой должности?

Какие бы вы задали вопросы нам, чтобы показать, что вы мыслите стратегически?

Какой алгоритм аудита проекта вы считаете правильным? Опишите его.

Представьте, что ваша команда вынуждена на неделю прервать работу над проектом (например, изменились бизнес-требования по проекту и заказчик попросил заморозить проект на неделю) Как вы построите работу команды на этой неделе? (Команда: аналитик, ведущий тестировщик, и джун тестировщик)

Есть рабочая коммуникация по следующей схеме Аналитик делает постановку => Тестировщик тестирует её => Тестировщик передает на разработку протестированную постановку => Разработчик передает готовое разработанное приложение тестеры на тестирование => Тестировщик находит много ошибок и возвращает приложение на доработку. Какой инструментарий вы бы применяли для оценки этого процесса? На каких “стыках” есть потенциальные опасности, поясните свою мысль? Что бы вы изменили в этом процессе?

* * *

От постоянного Клиента к нам пришел срочный заказ: «Сделать мобильное приложение наiOS/Android, которые бы использовали данные изPower BI».

Условия:

1. Дедлайн — 1.5 календарных месяца, начиная с сегодняшнего дня.
2. Предварительная оценка на мобильный проект 400 на каждую платформу, 300 бэкенд.
3. Задачу сPower BIвыполняет сторонняя команда, но на нашей стороне необходимо готовить данные, предварительно это займет около 20 часов в неделю бэкенд разработчика.
4. На стороне клиента: менеджер проекта (работает непосредственно с вами), руководитель отдела и генеральный директор. Менеджер (клиента) проекта должен утверждать части выполненных работ и готовый продукт с руководителем отдела. Готовый продукт всегда утверждается у генерального директора, по прошлому опыту на это уходит около одной недели.

CTOподготовил для вас: 1 бэкенд разработчик, 1iOSразработчик, 1Androidразработчик, 1QA+ обещание передать любых разработчиков в течение 2-х недель после запроса. Так же у вас есть дизайнер, готовый работать фултайм.

На получение фидбека отQAи исправление багов уходит 2 недели.

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

СЕО сообщил: «Проект важный и вы можете мотивировать разработчиков бонусами, не более 20% от заработной платы в месяц»

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

Опишите, пожалуйста:

1. План А и План Б для разработки этого проекта простыми человеческими словами.
2. Общие риски проекта и план, если риски срабатывают.
3. Подготовьте упрощенные диаграммы Ганта для каждого плана, чтобы были видны все роли и общий таймлайн.

* * *

Часть 1

Уважаемый кандидат! В настоящем задании представлено краткое описание предполагаемой ситуации. Пожалуйста, проанализируйте её и ответьте на вопросы в письменном виде:

1. Что сделать менеджеру проекта?

2. Как ему избежать подобных проблем в будущем?

Описание предполагаемой ситуации

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

В команде работала пара технических лидеров – атомные ледоколы, которые, куда скажешь, туда и плывут. Настойчиво, целеустремленно и неутомимо. И было несколько стажеров и малоопытных специалистов.

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

Алексей, видя активность в работе специалиста, а также его отдачу в проекте, понимал, что надо парня двигать вперед. Но как это делать, Алексей не понимал. Точнее, не было времени. Новую функциональность надо было выпускать каждый месяц, а это требовало пристального внимания руководителя. Кроме этого, команда укладывалась в сроки только благодаря наработкам этого специалиста. Алексей понимал, что переведи он ценного специалиста на другой проект, он гарантированно не сможет обеспечить выполнение обязательств по уже заключенным компанией договорам с данным ключевым Заказчиком. «Но делать с парнем что-то надо, – думал Алексей, – рано или поздно ему все это надоест».

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

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

До встречи со специалистом, на которой Алексей должен был объявить ему о новой работе, оставался еще час. Нужно было что-то придумать.

Часть 2

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

Описание предполагаемой ситуации

Вы руководите проектом по разработке новой информационной системы, используя Scrum. В вашей команде 2 разработчика (Алексей и Михаил), аналитик (Елена) и тестировщик (Артем). Вам необходимо составить план работ на первую 2х недельную итерацию, основываясь на оценках, которые вам сообщает команда.

При составлении плана стоит учесть, что задачи 1 и 2 могут выполняться параллельно, а задача 3 может зависит от выполнения задачи 2.

Подумайте над рисками, которые бы вы заложили в план итерации.  Какие вопросы вы бы задали команде в реальной ситуации?

* * *

Вы поставили программисту задачу: «Заменить все ссылки на сайте — на фиолетовые». От программиста поступил ответ: «Мне кажется, фиолетовый — это цвет самоубийц. Поменял на серые. Так круче!».

• Какие цели и интересы преследовал программист?
• Какие цели и интересы у менеджера в данной ситуации?
• Описать свои действия в такой ситуации, аргументировать их.

* * *

Зачем команде разработки нужен менеджер?

Кейс 1

Вы будете заниматься редизайном платформы IT-волонтёр. У вас в команде будет product owner, UX-дизайнер и три fullstack-разработчика. Команда распределённая. Основные цели редизайна:

1. Повысить вовлечённость волонтёров
2. Увеличить число решаемых задач
3. Сделать дизайн более современным

Не позднее 20 апреля 2020 года должна быть выпущена новая версия сайта.

Вопросы:

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

Кейс 2

Вы будете развивать платформу Теплосеть (ссылка протухла). В этой команде будет product owner, UX-дизайнер, специалист по геймификации, fullstack-разработчик. Команда распределённая.

Вопросы:

• Некоторые специалисты (дизайнер, геймификатор) будут заняты не только в этом проекте. Как вы будете договариваться о приоритете задач с коллегами из других проектов?
• Как можно сбалансировать работу над продуктовым бэклогом и багами/техническим долгом?
• Как провалидировать оценку сроков, данную разработчиком?

* * *

Вы вышли в логистическую компанию менеджером проекта на проект агрегатор курьеров. Менеджер продукта уже принял решение, что в начале надо делать регистрацию курьеров и просит вас подготовить требования для команды разработки. В разговоре он рассказал, что работаем только с курьерами с ИП и обязательно нужно собрать персональные данные (ФИО, паспорт, телефон и email). Т.к. рабочее место курьера — это мобильный телефон, то регистрация должна происходить там.

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

* * *

Тестовое задание (задание рассчитано на выполнение его около 4 часов, не тратьте на работу более 4 часов либо укажите итоговое время затраченное на выполнение).

Вам необходимо:

• Создать краткое ТЗ на создание сайта с функционалом регистрации 2 категорий пользователей (заказчик/исполнитель), чатом для обсуждения задачи и отметки о выполнении заказа заказчиком.
• ТЗ должно содержать графическую часть (прототип 3-5 основных страниц), описательную часть (1 страницу)
• Сделать описание декомпозиции и распределения задач между исполнителями/подрядчиками с учетом максимально сжатых сроков создания продукта.
• Описать свои задачи во время производства и внедрения продукта.
• Описать возможные риски по ходу разработки и способы решения проблемных задач.
• Описать необходимые ресурсы для решения задачи.

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

* * *

Задание 1.

К вам пришел клиент с заказом на мобильное приложение.
У вас есть: разработчики ios/android, ba,qa,дизайнер и вы — руководитель проектов.
Задачи:

• Спланировать разработку от старта до сдачи клиенту готового продукта.
• Составить и защитить план проекта перед заказчиком.

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

Задание 2.

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

Придя на данную встречу, Вы узнаете со слов специалиста отдела продаж, что они
нашли проект на доработку. Цель доработки проекта — реализовать перечисление
чаевых при оплате через банковскую карту в клиентских приложениях. Также
специалист по продажам упомянул про то, что есть готовое API, а исходники проектов
под NDA. Все эти материалы были направлены вам после встречи.

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

Вечером у Вас было совещание с портфельным руководителем.

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

Задание: Проведите все необходимые мероприятия по анализу и планированию
проекта от начала до сдачи клиенту. Финальные документы необходимо защитить
перед руководителем портфеля проектов. Он дал на выполнение задания 1-2 недели.
В компании процессы управления проектов проходят в соответствии со стандартами
PMBok, поэтому вам рекомендуется выполнять тестовое задание учитывая этот
стандарт.

* * *

Задание №1

Покупатель купил яблоки по цене $a и груши по цене $b потратив ровно $c (a, b, c вводится пользователем).

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

Задание №2

В Microsoft Excel есть три колонки Date; Project; Hours spent.
Посчитайте формулой по каждому дню и каждому проекту сумму Hours spent. Выведите формулой уникальные значения по колонке Project.
Посчитайте формулой сумму Hours spent по каждому проекту за все дни.

Microsoft Excel

Вам необходимо скачать файл “Тестовое задание на знание Excel” и переслать его обратно с готовым решением.

* * *

Кейс #1

Команда работает по двухнедельным спринтам. По окончанию итерации происходит релиз.

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

Как следует поступить с текущим спринтом?

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

Существуют ли критерии готовности историй для релиза? Какие? Кто их генерирует? Кто контролирует и принимает решение о готовности спринта к релизу?

Кейс #2

Для Data Science команды опишите процесс работы с гипотезами данных, этапы процесса, критерии прохождения каждого этапа.

Кейс #3

Приведите примеры метрик, которые описывают эффективность процесса разработки. Для 1-2 метрик опишите, как их можно измерять и с помощью каких инструментов

Кейс#4

Опишите отличия методологии Скрам от методологии Канбан. Как выбрать более подходящую для команды методологию?

Ранее я писал о пирамиде принятия решений. Сегодня хотелось бы поговорить об отличиях функционального уровня управления от операционного.

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

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

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

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

Качество системы определяется двумя параметрами:

1. Предсказуемость выдаваемых результатов.
2. Способность к самостоятельной работе.

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

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

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

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

1

Error happened.

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

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

Софт для календарно-сетевого планирования

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

Лучшее решение, которое я видел — плагин BigPicture для Jira. Позволяет брать реальные эпики и таски из джиры и из них делать «колбаски» ганта. Состояние задач в диаграмме будет апдейтиться автоматически. Даём гостевой доступ заказчику и ссылку на эту диаграмму и наступает общее счастье.

Если этот вариант невозможен, придётся использовать Microsoft Project для винды или аналоги для макоси, вроде Merlin Project или Omni Project. Все они устроены примерно одинаково.

Принципы ООП и основы программирования

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

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

Записываться на курсы разработчиков не нужно, это скорее навредит, чем поможет.

Умение собирать требования и писать ТЗ

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

Да, в скраме нет ТЗ, там есть стори. Но легче от этого не становится, фичи всё равно, нужно расписывать, если этого не делать, разработчики закодят трешню. А если закодят не трешню, на этапе приёмки заказчик вам скажет, что имел в виду не это и вы ничего не сможете доказать, придётся переделывать.

Базы данных вообще и SQL в частности

Суть большинства проектов сводится к тому, что нужно сходить в БД за данными, красиво их отобразить, дать пользователю отредактировать, потом провалидировать и аккуратно сложить обратно. То есть, всё завязано на БД.

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

Иногда бывает полезно уметь составить простенький запрос к какой-нибудь таблице с каким-нибудь условием.

Вот, например, код, выгребающий из одной базы подробную статистику трудозатрат по идентификатору доработки:

declare @id nvarchar(1000)
SET @id = 'CAS-191131-B8B3'


SELECT ROUND((SUM([Затраты])* 24), 2) as 'Итоговые затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]

WHERE Затраты IS NOT NULL 
AND [Запрос.Номер CRM] LIKE @id


SELECT Роль, ФИО, Тикет, ROUND((SUM([Затраты])* 24), 2) as 'Затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]

WHERE Затраты IS NOT NULL 
AND [Запрос.Номер CRM] LIKE @id

GROUP BY Роль, ФИО, Тикет
ORDER BY Роль, ФИО, Тикет

GO

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

REST и SOAP API

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

Научитесь читать и редактировать XML и JSON файлы. Если сильно не повезёт, вам могут поручить и проектирование API, у меня такое было раза три за карьеру.

Много очков в глазах работодателя даёт умение пользоваться Postman. Изучите его, он интуитивно понятный.

HTML и CSS

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

Потом научитесь пользоваться консолью разработчика, хотя бы в одном браузере. Очень важно уметь посмотреть, какие стили применились к данному элементу страницы и если надо, их подправить. Также нужно уметь пользоваться консолью ошибок, потому что первый вопрос, который вам задаст разработчик в ответ на ваше: «На сайте ошибка», будет: «Что в консоли?».

Во всяких бутстрапах разбираться необязательно.

Устройство админки популярных CMS.

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

Таблицы

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

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

Сюда же входят навыки по работе с реестром заинтересованных лиц и другими проектными таблицами.

Вот хороший телеграм-канал про секреты гуглотаблиц.

Основы девопс

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

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

Менеджмент

Менеджер продукта

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

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

Часто продакт работает в тесном контакте с дизайнерами, в результате такого сотрудничества вы вместе с продуктовой задачей будете получать и дизайн.

Если вы пиэм, продакт, как правило, не является вашим руководителем, скорее заказчиком.

Аккаунт-менеджер

Аккаунты встречаются напротив, в заказной разработке, где есть много общения с клиентом. Чаще всего аккаунт ведёт несколько проектов.

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

Эйчар

Эйчары бывают как в продуктовой, так и в заказной разработке.

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

Также эйчар периодически проводит контроль удовлетворённости сотрудников работой, может дать полезный совет.

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

Технический директор

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

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

Разработчики

Тимлид

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

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

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

Фронтенд-разработчик

Фронтенд-разработчики встречаются в веб-разработке. В крупных командах есть разделение на верстальщиков и именно фронтенд-разработчиков, но чаще верстает фронтендер.

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

Делает он всё это, как правило, на JavaScript. В чистом виде JS используется редко, чаще применяется один из JS-фреймворков, например React, Vue или Angular.

Бэкенд-разработчик

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

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

Хорошие бэкендеры владеют несколькими языками программирования: C++ или C#, PHP, Python и фреймворками, которые сильно облегчают им бэкенд-разработку. В случае, например с PHP, это Laravel или Symphony, для Python популярен Django.

Если нет девопса (о нём ниже), чаще всего вопросами гита и развёртывания тоже занимается один из бэкендеров.

Мобильный разработчик

Обитают в компаниях, занимающихся разработкой приложений для смартфонов. Рыночек порешал так, что фактически осталось две платформы — Android и iOS. Соответственно, разработчики делятся на три группы — андроидщики, айосники и специалисты по кроссплатформенной разработке.

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

Айосники обычно пишут либо на Swift (чаще), либо на Objective С (реже). Андроидщики — на Java или более новом Kotlin.Технически подкованные ведроводы, пищущие особо сложные приложения или игры, используют C/C++

У специалистов по кроссплатформе всё сложно.

Quality assurance

Мануальный тестировщик

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

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

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

Когда-то путь тестировщика считался самым простым способом входа в айти. В 2022 требования к ним сильно выросли, современный тестировщик должен уметь развернуть на своём компе ветку разработчика, постучаться в API при помощи Postman или Swagger, отлично уметь пользоваться консолью разработчика в браузере и не только в Хроме, а вообще во всех, уметь составить запрос к БД и многое, многое другое.

Самые системные и коммуникабельные тестировщики становятся лидами тестирования и начинают относиться уже больше к менеджменту.

Тестировщик-автоматизатор

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

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

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

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

Пишут автотесты они на скриптовых языках, прежде всего на Python и JS. Используют массу инструментов, например, Selenium и Protractor.

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

Дизайнеры

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

Функция UX (User Experience) ближе к аналитикам. В рамках этих задач дизайнер определяет, как будет работать интерфейс, его логика. Как сделать, чтобы интерфейс был максимально простым, не вызывал у пользователя желание обратиться в саппорт.

Функция UI (User Interface) уже чуть более «творческая». В рамках этих задач дизайнер определяет, как будет выглядеть интерфейс, его внешний вид. Эти функции неотделимы.

Так как проработка дизайна в том виде, в котором он будет готов для вёрстки, требует много времени, дизайнер интерфейсов должен уметь рисовать «вайрфреймы». Это такие наброски интерфейса, которые можно набросать за несколько часов и по которым уже можно судить, насколько это будет удобно использовать.

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

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

Аналитики

Бизнес-аналитик

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

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

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

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

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

Системный аналитик

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

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

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

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

Сисадминская братия

Системный администратор

Обычно при слове «сисадмин» люди представляют грустного бородатого человека в свитере с оленями, который заправляет картриджи и перезагружает роутер. На самом деле, сисадминов множество видов и они отличаются друг от друга ещё больше, чем различные дизайнеры.

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

Хорошие сисадмины умеют кодить на некоторых специфических языках, чтобы автоматизировать свои задачи и как можно меньше работать руками.

В целом, они как электрики, вы с ними будете взаимодействовать редко, но без них жить невозможно никак.

Девопс

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

Эти ребята могут разворачивать процесс непрерывной интеграции и развёртывания при помощи разных инструментов — Git, Docker, Kubernetes, уменьшая тем самым головную боль программистов. Автоматизируют процессы в Jira, уменьшая головную боль всех остальных участников процесса и повышая связность системы. Также настраивает мониторинг всех развёрнутых контуров, контролирует работоспособность.

В разработке высоконагруженных приложений, девопсы бесценны.

Администратор баз данных

Достаточно редкие звери в современной разработке, за 13 лет работы я встречал выделенного dba-шника всего один раз. Нужен там, где много баз данных, все они здоровенные и критически важные.

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

Чаще всего же на dba экономят и всё это делает девопс или сисадмин.

Прочие специалисты

Контент-менеджер

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

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

Особенно весело, когда на сайте часть информации сделана средствами CMS, часть хардкодом и нужно поменять и то, и то.

Маркетолог

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

Например, вас могут попросить реализовывать нетипичный интерактивный элемент на сайте, лендинг (обычно по готовому дизайну, с чёрным фоном, конечно же), современный маркетолог может запросить ещё и телеграм чат-бота.

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

Технический писатель

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

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

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

Чаще на техписе экономят и инструкции пишет либо кто-то из аналитиков, либо вы.

Специалист по информационной безопасности

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

ИБ — это уже чисто айтишники.

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

В общем, с этими ребятами надо дружить.

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

Сохранять молчание

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

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

Работать в нерастущей организации

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

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

Хотите вырасти — идите в растущие организации, в которых постоянно открываются новые направления и бизнес-единицы. Это не даёт никаких гарантий, более того, у такой компании выше риск обанкротиться, но это даёт шанс.

Терять энтузиазм в случае отказа

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

Шантажировать

В статье о безответственных сотрудниках я писал, что если человек употребляет фразу: «Не нравится, как я работают — увольняйте», его надо аккуратно и быстро уволить.

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

Об опциях к приложениям

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

Потом разработкой стали руководить маркетологи и стали рождаться приложения с двумя-тремя настройками. Принцип — не заставляйте пользователя думать.

Сейчас ситуация средняя. В Макоси, например, сделали иерархию, оставив на самом верху системных настроек минимум разделов. В приложениях Майкрософт Офиса тоже отказались от полотен настроек, сделав всё компактно. В приложениях, которыми я пользуюсь активно — Mail, Ulysses, Agenda, Evernote, Todoist, тоже среднее количество настроек. Думаю, такая детализация опций сохранится и в ближайшем будущем.

О скрытых убийцах

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

Совершенно бессимптомно может протекать гипертоническая болезнь. У вас может быть давление в потолок, которое никак не будет себя проявлять, не будет ни головокружения, ни отёков ног, ничего. Просто оно вас убъёт сильно раньше отведённого срока. Стоит купить прибор для измерения давления и время от времени его измерять.

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

Напишу точные названия нужных анализов:

• Гликированный гемоглобин HbA1С (HbA1С, Glycated Hemoglobin, GHB)
• Глюкоза (Glucose)
• Инсулин (Insulin)
• Холестерин общий (Холестерин) (Cholesterol Total)
• Холестерин ЛПНП (Холестерин липопротеинов низкой плотности, ЛПНП, β-холестерин) (Low-Density Lipoprotein Cholesterol, LDL Cholesterol)*
• Холестерин ЛПВП (Холестерин липопротеинов высокой плотности, ЛПВП, α-холестерин) (High-Density Lipoprotein Cholesterol, HDL Cholesterol)

Об общественном устройстве будущего

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

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

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

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

Сейчас никаких «общечеловеческих» ценностей в мире нет и их никогда не было. Гугл говорит, что сейчас в семи странах практикуется каннибализм и это укладывается в рамки их морали. Но эти ценности появятся по мере формирования этого самого глобализированного общества.

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

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

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

Но до гофрированных трубок пока далеко.

О том, как важно иногда сдаваться

Решил посмотреть сериал «Выбывшая» про Элизабет Холмс и её детище. В очередной раз убеждаюсь, что излишняя целеустремлённость и упёртость может навредить. Я как-то писал о том, что иногда вовремя сдаться и попросить о помощи — лучшая стратегия.

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

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

Очень важно вовремя остановиться.

Об аббревиатурах

Одна из особенностей госов — любовь к аббревиатурам. Она начинается в плоскости всяких МБОУ и ЕГАИС и простирается дальше, в том числе на айти-продукты. Из-за этого приходится после трудоустройства долго и упорно эти аббревиатуры учить, собирая по разным источникам, потому что единый словарь составить невозможно.

Бизнес-подход к названиям мне нравится больше. Например, однажды я работал на украинскую компанию, занимающуюся всякой криптохернёй и у неё продукты назывались максимально мнемонично. Штука, анонимизирующая транзакции — «Чёрный плащ». Штука, раздающая криптокошельки — «Крипторевольвер».

Или Систех. Приложение для мобильной торговли называется «Мобильная торговля». Приложение для отслеживания торгпредов — «Локатор». Приложение для репликации данных — «Репликация». Приложение для OLAP-кубов — «Аналитика OLAP»

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

О хобби и KPI

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

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

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

Не вешайте на хобби KPI и будет вам счастье.

О важности своевременного отключения рефлексии

В «Клинике» был эпизод с соревнованием хирургов. Умница Тёрк был уверен, что победит, он же так много всего знает и умеет. И вот, он подходит к доске с рейтингом и обнаруживает, что первый — туповатый Тодд, а Тёрк всего лишь второй.

Тёрк идёт к главному хирургу Вэнгу и спрашивает, как так получилось. А тот отвечает — ты зачастую слишком много думаешь.

Ну да. Тёрк такой: «А какой доступ лучше сделать, а что будет, если не удержим давление, а что будет, если он начнёт кровить…» А Тодд в то же время: «Тум-тум-тум, красивый скальпель, тум-тум-тум, пора порезать». И добивается успеха.

В условиях неопределённости и суженного до десяти минут горизонта планирования, в менеджменте тоже часто первыми оказываются не Тёрки, а Тодды.

О документах с полосочками

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

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

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

Полосочки в документообороте должны умереть.

О подписках на селебрити

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

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

О чипировании в гуглодоках

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

Вводите @ а после него название чипа и гуглотаблицы подскажут подходящие варианты. Добавление чипа человека не открывает ему доступ к документу.

Ещё через меню «Вставка» такое можно сделать.

Об упущенных возможностях и разновидностях пальто

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

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

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

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

— Как же так получилось? Я был абсолютно уверен, что вы давно гендиректор какой-нибудь розничной сети или депутат облдумы, с такими-то коммуникационными навыками.

Армянин страшно смутился:
— Ну, знаете, там люди поумнее меня будут. А вообще, сейчас носят приталенные, чуть выше колена. Я не шучу, снимите шапочку и примерьте этот экземпляр. Так, он немного пустоват, но я не шучу — полчаса и мы переставим пуговицы на сантиметр правее и оно будет как раз. Пожалуйста, не думайте, что я давлю, одно слово и мы будем смотреть другие варианты. Кстати, не подумайте, что я пытаюсь вам что-то впарить, но специальные щётки далеко шагнули вперёд, есть несколько штук. Да, и этот шарфик вместе с приталенным пальто называется «Стиль Владимир Путин»…

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

Пальто, кстати, я у него купил.

Об обуздании зума

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

Опции → Звук → Автоматически включать звук компьютера при входе в конференцию.

Мгновения бесполезных действий сплетаются в года, их надо экономить.

Снова о приоритизации

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

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

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

О цифровых активах

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

Или какая-нибудь критичная для бизнеса интеграция перестаёт работать, потому что её не оплатили по причине из первого абзаца.

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

Если же вы маленькие и для вас такое ту матч, пусть всё важное регается на гендира.

О первом диске

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

Мы отправились в Калининград, чтобы встретиться с главным редактором молодёжной газеты «Радуга», чтобы он нас научил, как делать газету лучше. Подробностей этой встречи я не запомнил, кроме того, что редактор, похоже, спал на работе и сильно пах потом. Зато на обратном пути я заглянул на рынок и купил вот этот замечательный диск с фотошопом, мануалами и плагинами.

Об обновлении на Вентуру

Для маководов. Три дня как обновился на Вентуру (13.0) Где-то полчаса качался дистрибутив, ещё полчаса система обновлялась. После обновления показала небольшую презенташку.

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

Со второго раза система переустановилась, флешка увиделась.

В предыдущей макоси говорилка текущего времени говорила его ровно сутки с момента включения, потом вырубалась. Теперь, вроде, не вырубается.

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

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

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

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

UPD: Я неправ, ящики отваливаются, звук глючит. Всё стабильно.

О важности протестов

Давным-давно я работал аналитиком в одной софтверной компании. И был у нас сайт с контентом, довольно популярный. У кого-то из руководства возникла светлая идея расположить сразу под шапкой специальную строчку, после наведения курсора на которую разворачивалось поле с функциональными подсказками о том, как лучше использовать наш сервис. Ну, типа как в играх: «Если хотите кого-нибудь застрелить, стреляйте, если не хотите — не стреляйте».

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

Гендир сказал, нет, вы неправильно подходите к задаче. Вдруг у нас возникнет необходимость потом добавить ещё подсказок? Каждый раз дизайнить и верстать? Сделайте лучше универсальный инструмент, типа конструктора, чтобы маркетологи могли создавать такие подсказки без программистов. Перечить гендиру никто не смел, взялись за работу.

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

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

Пришлось этот конструктор с позором выпилить и о подсказках забыть. Я не берусь подсчитать, сколько денег мы в эту функциональность закопали. И всё оттого, что ни у кого не хватило духу сказать гендиру: «Нет, мы не будем делать эту херню».

О самой дорогостоящей ошибке

В посте «Самая дорогостоящая ошибка, допущенная на работе», реддитор ZestyPing написал:

Я встретил Carl Page и Larry Page в 1998 году на вечеринке, которую организовал мой друг в Стэнфорде. 

Carl вручил мне визитку от eGroups и сказал «мы принимаем на работу». Потом Larry вручил свою от Google — дешевый кусочек картона, текст на котором очевидно был распечатан на струйном принтере — со словами «мы принимаем на работу».

Я сказал, «Не-а. Разве кому-то нужен еще один поисковик?» и ушел получать высшее образование.

Визитка все еще у меня.

О важности работы и участия заказчика

Работа заказчика для реализации проекта не менее важна, чем работа исполнителя.

Год 2008, лето, код 4012. Я только-только закончил университет и хочу немного передохнуть от айтишечки. Покупаю давно желанный фотоаппарат и начинаю учиться снимать. На дне города случайно знакомлюсь с директором калининградского агентства развлечений и он приглашает меня поработать на него фотографом. Почему бы не совместить увлечение с заработком?

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

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

1. Референсы внешнего вида.
2. Контент.
3. Чтобы он оплатил хостинг и домен, админпанель хостинга надо регать на него.

Хорошо, говорит он. На этом вопрос сайта встаёт на паузу. И далее, где-то два раза в месяц у нас повторялся разговор:
— Как у нас дела с сайтом?
— Ну, мне нужны референсы, контент и домен с хостингом.
— А, хорошо.

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

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

О теории и практике

Я хотел бы набросить на вечный вентилятор спора, что важнее, теория или практика. Как правило, в описаниях курсов сейчас пишут: «Только практические рекомендации, никакой воды» и считается, что это хорошо. Только практика, только реальные кейсы, только хардкор. 

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

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

Так и лощёному скраммастеру с макбуком не будет лишним освоить тяжеловесные методологии прошлого и основы объектно-ориентированного программирования. Эти знания могут совершенно неожиданно оказаться полезными в условиях современной гибкой разработки. 

О карьерных манипуляциях

А ещё вот как бывает. Вам накидывают обязанностей или повышают по грейду и повышают зарплату. Это называется карьерный рост.

А иногда просто накидывают обязанностей, но зарплату не повышают. Это называется карьерный нарост.

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

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

Плюс минус

Вычитал в Википедии про показатель «плюс-минус» в профессиональном хоккее. Его придумали в пятидесятые годы прошлого века, но считать для всех игроков НХЛ начали в 1967 году.

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

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

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

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

Об источнике задачи в джире

Совет по Jira. Кому-то он покажется очень очевидным, но другим сильно поможет. Особенно актуально для больших компаний.

Заведите для задач кастомное поле «Стейкхолдеры» и сделайте его обязательным. В поле нужно писать, от кого прилетела задача. Не представляете, сколько времени уходит без этого поля выяснение, к кому обращаться с вопросами по доработке.

О мотивации

— А давайте введём систему мотивации!
— Отличная идея! Давайте введём систему KPI, при полном выполнении которой сотрудники будут получать 100 % переменной части, которую сейчас и так получают. А у кого будет меньше, будем снимать часть переменной части.
— Стой, у меня идея получше.

О важности грамотного завершения испытательного срока

Несколько слов о важности грамотного завершения испытательного срока.

Прочитал историю программиста Иннокентия, который устроился в одну модную и современную айти-компанию, но не поладил с менеджером. Токсичным оказался программист, если вкратце. Менеджер вёл с ним долгие беседы, пытался исправить ситуацию, но взрослых людей трудно перевоспитывать. Решил увольнять. Пиши, говорит, заявление. В 99 % случаев на этом всё успешно заканчивается, но не в нашем случае. Фигушки, ответил Иннокентий, платите мне два оклада, тогда уйду. А платить не хотелось.

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

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

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

В общем, завершение испытательного срока — это важно.

О незапланированных фичах

В появлении таких «незапланированных фич» прелесть геймдева.

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

Кейси Стенгел

Менеджер высшей американской лиги бейсбола

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

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

Депремирование

По ТК РФ уменьшать сумму оклада у сотрудника нельзя, поэтому при трудоустройстве часто применяется финт. У сотрудника спрашивают, сколько он хочет зарабатывать. Он отвечает, что x руб. Ему предлагают 60 % от этой суммы в виде оклада и 40 % в виде переменной части, успокаивая, что эта переменная часть практически всегда выплачивается полностью. Сотрудник провинился — к нему применяется уменьшение переменной части. Особенно этим славятся руководители, под руководством которых работают неквалифицированные сотрудники. Если хотите узнать об этом подробнее, посмотрите видео с канала «Все работы хороши». В отдельных компаниях применяются такие хитрые схемы оплаты, что сотрудник при определённых условиях может проработать месяц бесплатно или остаться компании должен.

Но мы-то с вами управляем не сотрудниками склада и не официантами, а высокооплачиваемыми, творческими и довольно востребованными на рынке труда людьми. То есть, вы платите такому человеку определённую сумму. Он косячит. И чтобы он косячил меньше, вы решаете заплатить ему поменьше. Что может вызвать такое действие? Только озлобление и открытие в фоновой вкладке хедхантера и линкадина.

Я поступал честнее. Сотрудник хочет получать x рублей. Я же предлагаю ему x в виде оклада и возможность заработать до x+30 %, если он выполнит определённые условия. Вот лишение части этих 30 % воспринимается намного спокойнее.

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

Увольнение

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

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

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

На этом арсенал наказаний 95 % руководителей заканчивается. Мы же разберём ещё несколько разновидностей.

Временное лишение интересных задач

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

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

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

Лишение привычного окружения

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

В твиттере был шуточный тред о системе офисных пыток:

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

— Рептилия Оля (@yashcheritsa) May 7, 2018

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

Лишение самостоятельности

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

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

Самостоятельное исправление ошибки

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

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