О следующем уровне

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

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

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

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

* * *

О контроле

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

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

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

* * *

О багах

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

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

Почтовый клиент Mail, который всегда был вылизанным, выдаёт вообще, несусветное, я даже это нормально объяснить словами не могу. В списке писем имена пользователей в некоторых письмах «трусит». Я, конечно, подумал, что в пицце с грибами попались не те грибы, снял скринкаст, показал сисадмину, он тоже это видит.

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

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

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

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

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

* * *

О валюте

В связи с преодолением рублём очередного дна.

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

* * *

Об OLE

Одной из вещей, больше всего удививших меня в самом первом компе, был реализованный в Windows механизм OLE. Object Linking and Embedding. То есть, вы можете вставить в документ файл любого типа, лишь бы он поддерживал этот механизм, файл будет слинкован с документом, изменения в файле будут отображаться в документе. Это казалось прям пушкой.

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

Будет здорово, если вы расскажете, как использовали OLE, а позднее ActiveX для каких-то более продвинутых вещей.

* * *

О мотивации

Пересматривал вчера «В Бореньке чего-то нет», понравился один момент. Режиссёр (Виторган) рассказывает своему другу-сценаристу (Демидов), что у него есть знакомый, производитель мебели. Не ширпотреба, а вполне нормальной мебели. И однажды этот мебельщик купил себе дом. Режиссёр его спрашивает, а ты мебель в этот дом, своего производства поставишь? А тот отвечает, нет, конечно, я хочу, чтобы у меня дома была нормальная мебель.

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

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

* * *

О боязни рисков

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

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

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

* * *

О важности критики

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

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

* * *

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

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

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

* * *

О навыках постановки задач

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

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

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

* * *

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

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

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

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

* * *

О стоимости владения сотрудником

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

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

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

* * *

О важности навыка

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

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

* * *

О специализации

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

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

Я за специализацию с разумным T-shape.

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

* * *

О замораживании процессов

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

Тайным знанием поделился инженер Microsoft Дейв Пламмер, который эту функцию и придумал.

* * *

О феминитивах

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

* * *

Об аэропортофобии

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

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

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

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

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

* * *

О зарплате

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

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

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

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

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

* * *

О фичеризме

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

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

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

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

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

* * *

О безопасности

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

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

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

* * *

О быстром улучшении работы компании

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

1. Добился бы максимально возможной специализации исполнителей. Реализовывать вьетнамский вариант, когда за каждую операцию отвечает отдельный вьетнамец за миску риса и сникерс, конечно, не надо, но и от режима «все делают всё, но никто толком не отвечает за конкретную задачу» надо избавляться первым делом.
2. Добился бы дублирования исполнителей для максимально возможного количества функций. Каждую операцию должны уметь делать, как минимум, два человека на случай отпусков, болезней, отгулов и внезапных увольнений. Люди также должны быть замотивированы подменять друг друга в таки ситуациях не только корпоративным духом. Хорошо работает матрица компетенций.

* * *

О перелётах

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

1. Хорошие наушники, обязательно с качественным шумодавом — наше всё.
2. Всем плевать на расписание. При выборе рейсов для полёта с пересадкой, закладывайте на пересадку не менее 4-5 часов (при условии, что вам не нужно менять аэропорт), опоздание на час-полтора, похоже, в авиации, вообще, не считается за косяк.
3. Идите на регистрацию сразу после её открытия, в Шереметьево адские очереди на регистрацию.
4. При формировании сметы для работодателя, побольше закладывайте на такси с учётом высокого спроса.
5. Хорошая, дорогая зарядка с четырьмя портами — прекрасное вложение денег. Поставить на зарядку одновременно ноут, смартфон, наушники и четвёртый гаджет (умные часы, например, но у меня это фонарик-павербанк) очень удобно.

* * *

О единомышленниках

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

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

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

* * *

О правде

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

* * *

О важности логов

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

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

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

Логи ошибок мастхэв.

О целях

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

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

1. Вам интересны и не вызывают отторжения.
2. Востребованы на рынке, причём, желательно, не только российском.

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

* * *

О prodoctoruv.ru

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

* * *

Расписание типичного рекрутера

* * *

О российских сериалах

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

А фраза: «Ситуация критическая, но не безвыходная», может стать девизом прожект-менеджера.

* * *

О маркетинге

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

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

* * *

О первом шаге к нулевому инбоксу

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

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

* * *

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

* * *

О важности выраженных достоинств

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

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

* * *

О мотивации продаванов

Два лучших способа полностью убить мотивацию продаванов:

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

* * *

О первой помощи при отравлении

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

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

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

* * *

О нежизненном обучении

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

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

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

У меня нет хорошего вывода к этому посту.

* * *

О важности веры в себя

Манчестер Сити – это очередной пример того, что если у вас есть упорство, трудолюбие, целеустремленность, вера в победу, неограниченное количество денег от арабских шейхов и 15 лет на эксперименты, вы всегда добьётесь успеха!

Надо просто верить в себя и не сдаваться!

* * *

О русских людях на фотостоках

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

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

* * *

О фотографии рабочего дня

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

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

* * *

Об информативности встреч в календаре

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

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

* * *

О личном рабочем месте

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

* * *

Об экологии и сменных аккумуляторах

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

А вот гнездо для проводных наушников, похоже, окончательно стало достоянием истории. Я где-то полгода назад писал, что купил Xiaomi Redmi Buds 3 Lite (1 280 ₽ на Али) и был разочарован. Пару месяцев назад решил взять модель посолиднее, а эти подарить маме. Выбрал в итоге Soundcore Life Note 3i (5176 ₽ на Озоне) из-за аппаратных кнопок. Благодаря этим механическим штучкам, полностью исключены паразитные нажатия. Нащупал, нажал два раза на левом, трек переключился. Нащупал, нажал два раза на правом — пауза. Басы, да и звук вообще, сильно качественнее, лучше микрофон, и, что самое важное, они намного увереннее держат связь со смартфоном (у старых во время ходьбы глючила связь с левым наушником, жутко раздражало), аккумулятора хватает на дольше, есть приложение с эквалайзером.

В общем, не стоит экономить на наушниках и они станут вашим верным и комфортным спутником.

* * *

О сигаретах

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

* * *

Об ошибках в UI

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

Карта памяти — это на самом деле флеш память телефона, а storage чего-то там — это MicroSD.

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

undefined — Оторвать руки — undefined

undefined — Нормально — undefined

undefined — Оторвать руки — undefined

undefined — Нормально — undefined

* * *

Об айтишных пенсионерках

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

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

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

* * *

О корпоративном обучении

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

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

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

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

Но без обучения никак нельзя.

* * *

О первой помощи подавившемуся

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

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

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

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

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

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

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

* * *

Об анонимных резюме

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

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

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

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

* * *

О вреде корпоративных блокировок социальных сетей и видеохостингов

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

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

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

* * *

О нейросетевом переводе нонфикшена

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

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

Что за книжки. «Беспроводные войны» о том, чем грозит превосходство Китая в 5g. «Об эскалации», подробное описание всех шагов политических кризисов, от простой напряжённости до глобальной ядерной войны. «Земля обетованная» с мемуарами Обамы. В общем, важные книжки.

* * *

О максимально жизнеспособном продукте

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

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

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

* * *

О передаче управленческой работы без передачи власти

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

Поясню.

• Определение размера зарплаты подчинённых
• Принятие решения о размере премии подчинённых
• Распределение и согласование отпусков подчинённых
• Принятие окончательного решения о найме сотрудника в подразделение
• Принятие окончательного решения об увольнении сотрудника из подразделения

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

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

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

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

О корпоративном дзене

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

Больше всего меня впечатлила инфа о том, что именно Сатья Наделла прекратил войну с опенсорсом и начал дружить с компаниями, всегда считавшимися заклятыми врагами Майкрософта.

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

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

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

* * *

Об осмысленности

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

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

* * *

Об оптимизации Избранного в Телеграм

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

* * *

О том, как ставить вопрос на собесе

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

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

Косвенное следствие. Совершенно бессмысленно спрашивать: «Расскажите, как вы делали x?» Надо спрашивать: «Как по-вашему, правильно делать x?»

* * *

О портфельном подходе

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

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

* * *

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

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

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

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

Оставляю ссылку на пост про грейды пиэмов.

* * *

О поедателях с цифровых помоек

Придумал термин «инфофриган». Это человек, который бесплатно потребляет слитые инфокурсы.

* * *

О мышках и ёжиках

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

Быть «белым» ёжиком довольно прикольно. Читал случай, как в такую компанию (автодилер) приехали три тётки из Роспотребнадзора с проверкой. Ну и стали намекать — было бы неплохо пообедать, было бы неплохо нас развезти после работы домой и всё такое. Ну и по окончании проверки гендир распорядился главбуху, чтобы тот написал в Роспотребнадзор официальное письмо, что его сотрудницы съели обедов и прокатали за три дня проверки на 12 тыс. руб., ну и счёт. Видеть их лица было особенным удовольствием. Проверку прошли.

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

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

Быть ёжиком прикольно.

* * *

О кабинетах руководителей

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

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

* * *

О табличках

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

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

Ссылка на канал.

* * *

О терминаторах на собеседовании

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

* * *

О вокабуляре

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

У меня было около 120 тыс., но это с учётом всех словоформ, мата и сленга.

Есть бот @Slov0bot, но он считает только в чатах, в которые его добавили. Личку анализировать не умеет. Печаль.

* * *

О редиректах

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

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

* * *

Об искусственном интеллекте

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

* * *

О целостности

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

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

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

Люди, как правило, целостны в своих недостатках.

* * *

Снова об онбординге

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

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

* * *

О вебмастерах

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

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

* * *

О роботе-психотерапевте

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

Новелла не слишком технологичная и без особой драмы, так что, рекомендовать не стану. А пишу о ней, потому что вчера прочёл в книге «ChatGPT и Революция Искусственного Интеллекта» Тимура Казанцева о том, что робот-психотерапевт Eliza существовал в прошлом, хотя и был довольно примитивен. В наше время многие люди используют ChatGPT в качестве психотерапевта, он их неплохо поддерживает, хоть и рекомендует иногда чушь. То ли ещё будет.

* * *

Об интересе и таланте

Наблюдение. Если у вас есть искренний устойчивый интерес к чему-либо, скорее всего, у вас есть к этому склонность или талант. И наоборот, если нечто вас совершенно не интересует, скорее всего, склонности к этому нет.

* * *

Об EDC

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

Посмотрел несколько видео подборки «Что в сумке», там, в основном, разные известные женщины и Даня Милохин. И чего там только нет. У Эммы Уотсон, например, есть даже свинка с мячиком и пушистая грелка, об которую она греется в самолётах. И ни у кого ни разу не встретил самого обычного простенького ножика. Я не говорю о страшных выкидухах с упорами, обычный няшный викторинокс. И вот как они обходятся без этого предмета, мне вообще неясно.

* * *

О поиске по архивам

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

* * *

О фамилиях

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

* * *

О невмешательстве государства и другом мире

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

Бизнесмен Стив Джобс договорился с другим бизнесменом, Майком Марккулой, получил деньги, сделал бизнес. Потом договаривался с другими инвесторами, получал деньги от них. И никакого участия государства, никакого. Я не слышал, чтобы Белый Дом заказал ему десять тысяч айфонов или Пентагон — айпадов.

Всё-таки, другой мир эта Америка.

* * *

О драме

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

Все же досмотрели первый сезон Last of us? Если не досмотрели, не читайте дальше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Классификация фреймворков

Бэкенд-фреймворки

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

Например, при помощи Django вы можете сделать админку с гридами, о которой я писал выше. Это фреймворк на питоне.

Ещё можно выделить:

• Symfony, Laravel — PHP;
• Express.js — JavaScript;
• Ruby on Rails — Ruby.

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

Фронтенд-фреймворки

При помощи фронтенд-фреймворков вы напротив, можете реализовывать веб страницы с богатым содержанием, различными элементами интерфейса, кастомными и стандартизированными контролами. Различные анимации тоже можно делать с их помощью. Как правило, речь идёт о JS-фреймворках, например:

• Angular;
• Vue.js;
• Svelte;
• React — формально это не фреймворк, а библиотека, но значение этого инструмента так велико, что его постоянно сравнивают с другими веб-фреймворками.

Фуллстек-фреймворки

Сюда относятся фреймворки, реализующие как клиентскую, так и серверную часть. Например, JS Meteor.

Возможности фреймворков

Важное для менеджера

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

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

В целом, это всё, что пиэму нужно знать о фреймворках.

1

1

1

Error happened.

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

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

* * *

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

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

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

Кроме того, в вашем продукте может потребоваться реализовать дорогостоящую функцию, которая уже сделана в стороннем сервисе на отличненько. Например, если вам нужны карты, целесообразно использовать API Open Street Map или Яндекс.Карт, это сильно дешевле, чем пилить собственные карты.

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

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

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

Различия REST и SOAP

Чаще всего в современной разработке встречаются REST и SOAP API. Давайте разберём, в чём разница.

Типы запросов

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

1. GET
2. POST
3. PUT
4. PATCH
5. DELETE

GET – используется для получения со стороны севера определенного ресурса. Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.

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

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

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

Postman

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

Есть публичное API для смешных переводов, например, эндопоинт для перевода на язык Мастера Йоды находится по адресу: https://api.funtranslations.com/translate/yoda.json

Эндпоинт принимает только один строковый параметр text. Отправим Постманом GET запрос на этот эндпоинт:

Как видите, API возвращает такой ответ:

{
    "success": {
        "total": 1
    },
    "contents": {
        "translated": "Force be with you yoda,Polovec helloy you",
        "text": "Hello Yoda, Polovec helloy you",
        "translation": "yoda"
    }
}

Как нетрудно понять, эндоинт возвратил код успеха, а в поле контента передал три значения:

• translated — переведённый текст.
• text — исходный текст.
• translation — тип переводчика.

По такому же принципу работают любые REST API, только в реальных запросах параметров больше и они сложнее.

Применение в реальной разработке

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

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

Разное

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

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

Вот ещё хороший документ про API от пользователя Koray OKE:

В целом, это всё, что пиэму нужно знать об API.

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

Для того, чтобы понять, зачем нужен Кубер, сначала нужно понять, зачем нужен Докер.

Docker

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

У вас может возникнуть вопрос, в чём разница докера и самой обычной виртуальной машины?

Контейнеры и виртуальные машины — это разные способы виртуализации. Только виртуалка реализует её на уровне железа, а Docker — на уровне операционной системы.

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

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

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

Если кратко перечислить преимущества контейнеризации, то это:

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

Все основные облачные провайдеры, такие как Amazon AWS, Google’s GCE, Microsoft’s Azure и даже Alibaba Cloud, предоставляют услуги по размещению контейнеров.

Докер работает на линухе. Чтобы использовать его на винде или макоси, нужно ставить виртуальную машину с линуксом. Теперь несколько слов о том, из каких компонентов состоит Докер:

• Docker host — это операционная система, на которую устанавливают Docker и на которой он работает.
• Docker daemon — служба, которая управляет Docker-объектами: сетями, хранилищами, образами и контейнерами.
• Docker client — консольный клиент, при помощи которого пользователи взаимодействуют с Docker daemon и отправляют ему команды, создают контейнеры и управляют ими.
• Docker image — это неизменяемый образ, из которого разворачивается контейнер.
• Docker container — развёрнутое и запущенное приложение.
• Docker Registry — репозиторий, в котором хранятся образы.
• Dockerfile — файл-инструкция для сборки образа.
• Docker Compose — инструмент для управления несколькими контейнерами. Он позволяет создавать контейнеры и задавать их конфигурацию.
• Docker Desktop — GUI-клиент, который распространяется по GPL. Бесплатная версия работает на Windows, macOS, а с недавних пор и на Linux. Это очень удобный клиент, который отображает все сущности Docker и позволяет запустить однонодовый Kubernetes для компьютера.

Основных сущностей для работы с докером три:

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

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

Вы вполне можете использовать Докер без Кубера, но Кубер даст дополнительные возможности.

Kubernetes

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

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

Кластер

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

Узел

Узел — это отдельный компьютер (физический или виртуальный). Его задача состоит в запуске подов. Каждый узел в Kubernetes содержит несколько компонентов, таких как kubelet и прокси kube. Все они находятся под управлением ведущего узла. Узлы — это нечто наподобие рабочих пчел, которые занимаются выполнением всех основных задач. Устаревшее название узла — миньон.

Под

Под (pod) — это единица работы в Kubernetes. Каждый под содержит один или несколько контейнеров. Поды всегда работают совместно, то есть на одном компьютере. Все контейнеры внутри пода имеют одни и те же IP-адрес и пространство портов, они могут общаться между собой через локальный сервер или посредством межпроцессного взаимодействия. Кроме того, все контейнеры имеют доступ к общему локальному хранилищу данных узла, на котором находится под. Такое хранилище может быть подключено к каждому контейнеру.

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

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

Несколько слов о возможностях Кубера:

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

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

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

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

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

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

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

В целом, это всё, что пиэму нужно знать про Докер и Кубер.

2

1

1

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 и гуглотаблицами, тем выше ваша продуктивность и ценность. В Скайэнге вообще, требуют в тестовом на пиэма задание, предполагающее написание макросов, но это единичный случай.

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

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

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

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

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

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

Мы семья

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

Мы хорошо работаем и хорошо отдыхаем

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

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

Неуважение в процессе рекрутинга

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

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

Слишком объёмные тестовые

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

Компания не понимает, кто ей нужен

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

Работодатель соврал в тексте вакансии

Самая частая ложь — в вакансии обозначена зарплата, условно, 100 000 руб., а на собеседовании выясняется, что у вас будет шанс достигнуть этой зарплаты после испытательного срока и проработав какое-то время (какое, не уточняется), а пока извольте работать за 60. Иногда говорят, что да, 100, но из них оклад 60, а 40 — премия. Это чуть менее критично, работодатели так часто страхуются. Но бывает, что и нет. Я однажды повёлся сразу на два пункта из этой статьи, на команду-семью и вот на этот пункт. Каждый месяц гендиректор вызывал меня в коридор (кабинета у него не было), мы гуляли взад-вперёд и он пытался доказать мне, что на премию я в этом месяце не наработал. 

Работодатель предлагает работу слишком быстро

Если вам предлагают работу после двадцати-тридцати минут собеседования, это плохой знак. Похоже, что в компании не настроен процесс отбора и работают в ней своеобразные люди. Меня однажды наняли по результатам чтения резюме и даже не голосового, а текстового собеседования. Я позадавал вопросы, гендир мне на них ответил и сказал, что я нанят. Эту работу я вспоминаю с содроганием. Ну и, кроме того, такой подход означает, что в случае малейших консёрнов, вас уволят так же быстро (в 100 % таких компаний какое-нибудь шуллерское оформление вроде самозанятости или ГПХ вместо нормального трудового договора). Слишком затянутый процесс найма, это тоже не есть хорошо, но это красный флаг в меньшей степени. 

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

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