Предположим, вы или ваше руководство пришло к выводу, что без мобильного приложения бизнес теряет прибыль и обойтись завёрнутым в какую-нибудь программную обёртку веб-сайтом никак невозможно, нужно пилить что-нибудь нативное.
У вас четыре варианта подхода к найму исполнителей.
Инхаус-команда.
Один или несколько фрилансеров.
Аутстаф команда под полным вашим контролем.
Подрядчик, которому вы поручаете работу под ключ.
У каждого варианта есть плюсы и минусы, давайте разбираться.
Инхаус команда
Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату.
Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры.
Большая ответственность ложится на рекрутера и нанимающего менеджера. Если они наймут недостаточно квалифицированных специалистов, вы потеряете довольно много денег на их зарплаты и урегулирование увольнений без суда (предполагаю, что вы работаете по белому).
Инхаус-сотрудников можно мотивировать корпоративной шизой, давить на совесть, просить переработать во имя будущих бенефитов и применять другие управленческие дарк-паттерны. Во всех остальных вариантах это будет затруднительно или невозможно.
Есть мнение, что инхаус-разработка стабильнее. Что у штатного сотрудника выше мотивация, он внезапно не пропадёт с радаров. Однако работодатели делились со мной историями, как штатный сотрудник просто переставал приходить в офис и брать трубку, даже не забирал трудовую.
Один или несколько фрилансеров
Главный плюс этого варианта — дешевизна. Вы можете найти фрилансеров на совершенно любой бюджет. Даже если у вас буквально три копейки, найдутся люди, которые выполнят заказ и далеко не факт, что некачественно.
Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании.
В остальном же, у этого подхода сплошные недостатки. Например, у фрилансера может быть основная работа, на которой сейчас его не слишком напрягают и у него есть время фрилансить, а через месяц ситуация поменяется. Без договора, фрилансер связан с вами только устными обязательствами и рискует только своей репутацией на данной площадке.
Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов.
За фрилансерами крайне желательно ставить наблюдать штатного специалиста, чтобы он проводил код ревью и добивался качественного, читаемого, поддерживаемого кода. Для того, чтобы когда вам придётся фрилансера заменить, новый специалист не потребовал переписать код с нуля, а мог нормально подхватить недоделанную работу.
Аутстаф команда под вашим контроем
Находите аустаф-компанию, договариваетесь о часовых ставках и грейдах, вам предоставляют специалистов. Вы ставите им задачи, они их пилят и отчитываются в какой-нибудь таск-трекер об отработанных часах. В конце месяца аккаунт присылает отчёт, вы проводите оплату.
Достаточно гибкий вариант. Вы так же, как с фрилансерами, можете формировать и перетасовывать команды как угодно. Если не нравится работа конкретного специалиста, не нужно думать, как его правильно уволить, просто просите аккаунта его заменить.
Недостаток метода в дороговизне. Аутстаферам нужно платить специалистам зарплаты и при этом что-то зарабатывать, поэтому это самый дорогой вариант.
Кроме того, аутстаферы не несут никакой ответственности за результаты и их крайне сложно этой ответственностью наделить. Вы самостоятельно должны их менеджерить, следить за постоянством загрузки и тем, чтобы они делали только приоритетные вещи.
Подрядчик для работы под ключ
Метод подходит для не очень сложных приложений, для которых вы можете составить полное ТЗ и делегировать его производство подрядчику, чтобы он сделал его водопадом за раз, за фиксированный бюджет.
В этом случае ТЗ можно приложить к договору, чётко оговорив критерии качества продукта, который должен получиться в итоге. Возможно, подрядчик захочет написать более детализированное ТЗ и согласовать с вами, на это уйдёт дополнительный бюджет.
Возникает вопрос, как потом поддерживать получившееся приложение. Тут возможны варианты, всё зависит от изменчивости среды и потока изменений. Можно заключить отдельный договор на сопровождение с этим же или другим подрядчиком.
Также возникает вопрос, как в этом случае проконтролировать качество кода с точки зрения последующего обслуживания, развития и доработок.
На практике рассмотренные методы хорошо и правильно комбинировать. Например, нанять инхаус лидов, а для исполнителей использовать аутстаф.
Описанные ниже практики могут показаться самими собой разумеющимися для опытных тимлидов и пиэмов, давно и плотно занимающихся профессиональной разработкой ПО. Однако, попав в стартап, можно обнаружить, что горе-фаундеры забыли их внедрить. Давайте о них поговорим.
Гит
На проекте я тимлид,
В мастер пушу свой коммит,
У меня на это есть
Полный доступ в гит.
Если команда проекта состоит из вас одного, да, можно заливать код по FTP и вносить правки прямо на прод. Но уже когда вас становится двое, начинаются проблемы. Вы будете затирать код друг друга, откат из серверной резервной копии будет занимать массу времени и проч. Кроме того, в процессе залития файлов через FTP, прод будет работать нестабильно. Гит решает все эти проблемы, у вас появляется нормальная версионность, нормальный мерджинг, нормальное залитие кода в прод. Первым делом в стартапе надо внедрить гит, если его ещё не внедрили.
Код ревью
Как и в предыдущем случае, если команда из вас одного, вы сами за всё отвечаете и качество кода только на вашей ответственности. Но как только появляется второй разработчик, начинаются риски, что он будет вливать говнокод с очень странными и неочевидными программными решениями. Код ревью надо внедрять вторым делом и никогда на него не забивать, даже в экстренных случаях, когда какая-то важная функция работает неправильно, иначе вы рискуете положить прод вообще.
CI/CD
Эту загадочную аббревиатуру нужно внедрять в третью очередь, когда гит и код ревью уже заработали. Даёт великое множество профитов — возможность гибко управлять правами доступа, автоматизировать ручные действия и самое главное, возможность нормально масштабироваться. Без CI/CD в случае резкого всплеска нагрузки вам останется только развести руками.
Прозрачный процесс постановки задач
В прошлом команды зачастую проживали несколько стадий — устная постановка задач, запись на листочках, запись на физической доске, обвешивание досками всего кабинета, депрессия, переход на таск-трекер.
В других компаниях руководство грешит тем, что кидается задачами прямо в почте или в чатах, потом удивляется, почему ничего не сделано и ничего невозможно отследить. В четвёртую очередь ставим таск-трекер и принуждаем всех пользоваться им. Если руководство слишком нежное, обязываем кого-нибудь наиболее ответственного из тестирования или, в крайнем случае, тимлида, преобразовывать эти потоки сознания в тикеты.
Руководитель изрыгнул в чат баг или очередную светлую идею — ответственный сотрудник заводит тикет в таск-трекере и скидывает в чат номер. Исключений нет.
Одна задача = одна ветка в гите.
Крупные задачи нужно дробить на мелкие. А для мелких заводить отдельные ветки. Причина проста. Если вы решите вести в одной ветке 10 задач и срочно потребуется релизиться, вы не сможете это сделать, если хотя бы в одной будет критичный баг. Если вести задачи в отдельных ветках, вы совершенно спокойно зальёте 9 рабочих веток с 9 рабочими задачами и обрадуете стейкхолдеров и пользователей.
Автотесты
Вам может показаться, что продукт слишком мал и прост для автотестов. Но проблема роста потому и проблема, потому что момент роста сложности трудно заметить. А без автотестов вы постоянно будете сталкиваться с тем, что вливаемые функции ломают существующие. А когда вы станете совсем большими, можете завести выделенный отдел автотестирования.
Мониторинг ошибок
Последний, но не по важности пункт, который надо внедрять в стартапе в обязательном порядке. Ставить систему мониторинга ошибок и настраивать этот самый мониторинг. Потому что иначе вы будете узнавать об ошибках от пользователей, как правило, с очень ограниченной информацией, вроде мутного скриншота и ещё более мутного описания последовательности действий. Ещё хуже, если к вам с ошибками будет прибегать кто-нибудь из топ-менеджмента, на этом ваша карьера в этом стартапе может быстро закончиться.
Мониторинг ошибок позволяет узнавать о багах по мере появления, надо только выстроить процесс так, чтобы на этот мониторинг ответственные лица не забивали.
Вот, в целом, и все полезные практики, которые вам нужно завести в свежем стартапе чем раньше, тем лучше.
Free cute chihuahua dog biting a shoe image, public domain animal CC0 photo.
Об интерфейсе планирования встреч
Идея для самого лучшего корпоративного плагина для гуглокалендаря. На основании часовых ставок сотрудников считает, во сколько обойдётся компании планируемое совещание и предлагает вместо этого отправить письмо.
* * *
Про кино и нейросети
Когда в кино показывают большой отрезок жизни человека, для его детства берут просто похожего ребёнка, а потом сразу показывают подростка или взрослого человека, которого играет взрослый актёр.
Чаще всего получается непохоже, мы всё-таки сохраняем большую часть детских черт, а тут разные люди. С показом человека в старости всё проще, накладывают старческий грим, серебрят волосы, дорисовывают графикой. Думаю, с ростом качества дипфейков этот подход изменится и взрослые герои станут реально похожи на себя в детстве.
Айти на службе кино.
* * *
О поисковиках
Я считаю главным достижением поисковика гугла умение находить нужный графический мем по описанию. А главным провалом — что он дал заднюю и разучился находить людей в соцсетях по фото.
* * *
Об онбординге
В книге «Звёздный десант» Роберта Энсона Хайнлайна есть эпизод, в котором курсант ударил инструктора. Из ряда вон выходящая ситуация, все на ушах. И капитан ругает… инструктора. Ты же профессионал, ты должен был вырубить его уже в тот момент, когда он только подумал совершить такое преступление, тем самым спасти мальчика от административного наказания (публичной порки).
Предположим, вы проводите онбординг нового сотрудника и в вашей компании есть, например, еженедельная отправка специфического отчёта, который будет читать, в том числе вышестоящее руководство. Большинство «инструкторов» просто уведомляет сотрудника о том, что надо писать отчёт, снабжает примерами и ждёт. Сотрудник делает отчёт с большим количеством ошибок, потому что он специфический. «Инструктор» обвиняет сотрудника в ошибках, сотрудник их итеративно исправляет, постепенно демотивируясь.
А нужно не дать ему совершить ошибку. Один раз сесть с ним и сделать этот отчёт вместе, объяснив, что и как писать в каждом разделе отчёта, помочь с формулировками. На второй и следующие разы — конечно, уже пусть делает сам и если будет косячить, указываем ему на это.
* * *
О цвете пояса
Каратистам, айкидошникам и другим восточникам по мере роста опыта и заслуг, присваивают пояса различных цветов, в разных школах они различаются. Но принцип один и тот же: когда-то давно бойцы, начиная карьеру, подпоясывались поясом белого цвета, он в процессе тренировок и боёв впитывал кровь и пот, постепенно темнея, отсюда и традиция.
Думаю, было бы интересно присваивать айтишникам какой-нибудь предмет гардероба, который бы менял цвет по мере выгорания владельца.
* * *
О сериалах для людей под сорок
На заре российского телевидения, там крутили сериалы, ЦА которых были пенсионеры, которым было интересно смотреть за всякими Просто Мариями. Почти одновременно с ними стали показывать контент до шестнадцати и старше, вроде «Друзей». И вот в последние годы я всё чаще замечаю сериалы, которые лучше всего отзовутся людям под сорок.
«After Life» (первый сезон), «Мистер Корман», «В Бореньке чего-то нет» (из отечественного) и вот теперь «Терапия». Там Джейсон Сигель, вылезший из образа Марша Сладенького, а также пожилой Харрисон Форд. Вышло пока три эпизода и да, это сериал для людей под сорок.
* * *
Об уверенных в себе людях
Все знают про эффект Даннинга-Крюгера. Дураки полны уверенности, умные люди полны сомнений. Но на уверенность в себе оказывает не только имеющийся набор знаний и опыта.
Дело в том, что умный человек видит больше вариантов развития событий и вариантов поведения в них, поэтому и может колебаться при выборе актуального. Дурак же видит один-два варианта событий и действует уверенно.
Бойтесь уверенных в себе людей.
* * *
О монетизации личного бренда
Став знаменитым, Сальвадор Дали перестал платить в ресторанах. Он приходил, пил, ел, а когда приносили счёт, выписывал чек на нужную сумму, а на обороте рисовал что-нибудь сюрреалистическое.
Рестораторы эти чеки никогда не обналичивали, а продавали на аукционах живописи за намного большие деньги. И все были довольны.
* * *
О детских бизнес-заблуждениях
Есть типовые детские заблуждения, они у всех более-менее стандартные, это не очень интересно. У меня же было несколько бизнес-заблуждений.
1. Был уверен, что заместитель директора — это такая мегасинекура. Человек вообще ничего не делает и начинает выполнять функции директора, только когда последний куда-нибудь отлучается.
2. Кадровик — невероятно могущественный человек, потому что решает, кого нанимать и кого на какую должность ставить. По сути, третий человек в компании, после пункта 3.
3. Офис-менеджер — это тоже мегамогущественный человек, потому что управляет неким конкретным офисом целиком, со всеми чадами и домочадцами.
* * *
О необычном использовании личного помощника
Вычитал интересную практику использования личного помощника. Предприниматель поручил помощнику прочитать десять лучших книг по маркетингу, а потом рассказать ему самое интересное. В итоге узнал ОЧЕНЬ много интересного о маркетинге, потратив всего час времени на разговор вместо двух недель чтения, которых у него из-за постоянной занятости не было.
И такое можно делегировать.
* * *
О странном UI
Приз за самое странное UI-решение получают дизайнеры Майкрософта. Вот эта панелька в веб-версии Тимс меняет ширину, в зависимости от… чиселок в времени длительности разговора, которые набраны пропорциональным шрифтом. Панелька укорачивается на несколько пикселей, если во времени количество минут или секунд содержит единичку и отпрыгивает назад, когда чиселка меняется.
* * *
О важности своевременности
Из-за постоянно изменяющейся среды, старый опыт чаще всего, не особо актуален. То, что не работало в 2010 г., вполне может заработать в 2023. То, что работало тогда, может не заработать сейчас.
Представьте себе попытку сделать какую-нибудь Яндекс.Музыку в 2002 году на российском рынке с кнопочными телефонами и людьми, которые видели банковские карты только в рекламе по телику. И вот, спустя всего десять лет она отлично запускается и работает.
Представьте сервис, просящий доллар за скачивание рингтона для телефона в 2023. Глупость? А не так давно контент-провайдеры отлично на этом зарабатывали.
И ещё совершенно не факт, что в этом безумном мире и в этой безумной стране колесо истории сделает оборот и эти способы заработка снова заработают. Опыт переоценён.
* * *
О вырезании фона
В Вентуре можно встроенными средствами удалять фон с изображения. Жмякаем правой кнопкой → Быстрые действия → Удалить фон.
Попробовал на картинке со сливающимся фоном, получилось сносно.
* * *
О вкатывании в айти
Лучший способ вкатиться в айти в 2023 — чтобы вас покусал другой айтишник.
* * *
Конфуций об онбординге
Расскажи мне и я забуду. Покажи и я запомню. Дай мне сделать и я пойму. (приписывается Конфуцию) Это не баянистая присказка, а истина.
* * *
О выражениях в официальной документации
Как-то спала мода на опросы. Давайте исправляться. Имеем большую компанию с кучей начальников, некоторые из которых любят заглядывать в проектную документацию с разными целями. Как вы считаете, формулировка «Второй вариант архитектуры выглядит любопытным» в протоколе созвона (внутреннего) — это приемлемо или так писать нельзя?
* * *
Об айтишном джокере
В нолановской трилогии Джокер говорит, что больше всего на свете обожает бензин и динамит, потому что они дёшевы и с их помощью можно навести много шороху.
Когда будет время, напишу рассказ или даже книжку про айтишного Джокера, который обожает эксплойты и сканеры уязвимостей, потому что они мало весят и с их помощью можно тоже навести немало шороху.
* * *
О народных псевдоприметах
Некоторые «народные приметы», которым нас в детстве учили бабушки и дедушки, имели под собой вполне материальную основу.
Например, меня учили ни в коем случае не наступать на канализационные люки, плохая примета. Но ведь это логично, люк может быть плохо закреплён, есть риск упасть и переломать ноги.
Или обходить столбы и дорожные знаки только с дальней от дороги стороны, если обходить близко к дороге, плохая примета. Всё верно, чем дальше от дороги, тем ниже риск быть сбитым каким-нибудь дураком.
Но одна вещь осталась для меня непонятной. Зачем они говорили, что если заснуть на левом боку, приснится кошмар? Меня это так впечатлило, что все три или четыре раза, которые я за детство уснул на левом боку, снились лютые хорорры. Уже потом, когда я понял, что это всё херня, стал спокойно спать на любом боку. Какую цель ставило перед собой приучение спать только на правом боку?
А вас учили каким-то приметам, под которыми была здравая основа?
* * *
О ворклогах
Один из самых страшных вопросов, который может задать руководитель начинающему специалисту: «А что конкретно ты делал всю неделю?» Я столкнулся с ним, когда в молодости предпринимал первые попытки сисадминить. Проблема в том, что делаешь массу мелких вещей и совершенно их не помнишь, а ответ: «Делал множество мелких вещей» руководство не устраивает.
И я приобрёл привычку записывать ВСЁ, что делаю. Эвернота тогда не было, зато был майкрософт аутлук, синхронизирующийся с КПК и я струячил туда всё:
У бухгалтера слетел банк-клиент. Исправил.
Настроил секретарше номера быстрого набора на телефоне.
В удалённом офисе засбоил почтовый сервер. Подключился, настроил, вроде, почта снова ходит.
Завёл в AD учётку нового пользователя (финансы).
Переустановил винду на ноутбуке офис-менеджера. Настроил бэкап Акронис, чтобы больше не тратить на это время.
И так далее.
И так далее. И когда руководитель радостно спрашивал: «А что конкретно ты делал на этой неделе?», уже предвкушая как лишит меня премии, я спокойно печатал эту простынь и подносил ему в папочке. Обычно он на это хмурился, отвечал, что такие подробности его не интересуют и отставал надолго.
Когда перешёл в разработку, этот вопрос стал звучать реже, потому что есть джира и дневные отчёты. Но пару раз за карьеру менеджера проектов всё же слышал этот самый вопрос.
В общем, если вы только начинаете карьеру, рекомендую завести полезную привычку вести такие ворклоги, это не очень затратно и легко затыкает разных высокопоставленных дураков.
* * *
О личных качествах обучающего
В крупных продуктовых и во многих аутсорсных компаниях изобретают собственную методологию управления проектами, со своими выстраданными процессами и правилами. В компании может быть своя система проектной документации, особый подход к ведению требований и другие формальные аспекты, которым новичков нужно обучать.
Возникает соблазн делегировать роль «тренера» самому знающему и опытному пиэму. Я же рекомендую назначить для этого необязательно самого знающего, но обязательно самого доброжелательного и терпеливого специалиста.
Скорость обучения у всех новичков разная. Кроме того, некоторые из них могут плохо воспринимать на слух и лучше понимать текст, другие наоборот. Опытный и знающий начнёт по привычке требовать и давить, а может и оскорблять и угрожать карами, что приведёт только к тому, что вы потеряете часть «учеников».
Доброжелательность и терпеливость — вот ключи к успешному обучению. Ну и обязательно нужно сочетать методы. Рассказать в общих чертах, показать, как это делается, дать «ученикам» задание на дом, чтобы закрепить навыки и снабдить текстовыми описаниями, чтобы использовать их в качестве справочника.
* * *
О мегатрендах
Если бы я мог выделить один глобальный тренд в бизнесе в 2022 году, это было бы желание потребителей прозрачности. Желание понимать, из чего складывается стоимость услуги, что входит в состав товара и всё такое. Игнорировать этот тренд можно, но те, кто ему следуют, зарабатывают больше.
* * *
О видах прогресса
В продолжение поста о наставничестве. Бывают разные типы прогресса и к ним всем нужно относиться спокойно.
* * *
О странных запросах в техподдержку
Техподдержка регулярно сталкивается с самыми чудными запросами пользователей, но самое интересное я узнал вчера. Чувак был уверен, что его логин и пароль от одного сайта подходят ко всем сайтам в интернете
* * *
О разнице между спамом и флудом
Спам — это рекламное сообщение, которое пользователь не запрашивал. А флуд — поток навязчивых сообщений, необязательно рекламных. Почему-то 99 % пользователей путают спам и флуд.
* * *
Об эмблемах
Вы когда-нибудь думали о том, что на иконке Android Studio – циркуль, изящный и точный инструмент инженеров и архитекторов, а на иконке Xcode — молоток?
Когда-то давно разработчики писали софт с нуля. Нужна тебе, к примеру, функция, делающая текст капслоком, берёшь и пишешь. Надо решение квадратного уравнения — берёшь и пишешь модуль для решения квадратного уравнения руками. Наиболее сообразительные программисты достаточно быстро поняли, что часто используемый код можно стандартизировать и стали писать библиотеки готовых модулей. Появилась возможность импортировать в свой проект чужую библиотеку и обращаться к уже написанным и отлаженным методам.
Приложение, использующее библиотеки, состоит из основного кода разработчика, который обращается к библиотекам, вызывая методы из них.
Однако через некоторое время выяснилось, что можно ещё сильнее ускорить разработку. Например, в огромном количестве веб-проектов нужно писать веб-админку с более-менее стандартными гридами. Ну или часто пишутся сайты с более-менее стандартизированной вёрсткой. Выделение таких программистских потребностей привело к появлению первых фреймворков. Слово «фреймворк» переводится как «каркас».
Приложение на фреймворке содержит код фреймворка в своей основе, каркасе, и вызывает код разработчика, который выполняет специфические для этого приложения функции, в этом его архитектурное отличие от приложения с вызовами библиотек. Впрочем, никто не мешает комбинировать эти подходы и использовать в приложениях на фреймворке подключение библиотек и вызовы методов из них.
Классификация фреймворков
Бэкенд-фреймворки
Эти фреймворки предназначены для реализации серверных функций приложения. Веб-страницы с их помощью делать можно, но только самые просты.
Например, при помощи Django вы можете сделать админку с гридами, о которой я писал выше. Это фреймворк на питоне.
Ещё можно выделить:
Symfony, Laravel — PHP;
Express.js — JavaScript;
Ruby on Rails — Ruby.
Все эти фреймворки имеют на борту функции формирования выходных данных, с их помощью можно релизовывать безопасность серверной части от попыток взлома.
Фронтенд-фреймворки
При помощи фронтенд-фреймворков вы напротив, можете реализовывать веб страницы с богатым содержанием, различными элементами интерфейса, кастомными и стандартизированными контролами. Различные анимации тоже можно делать с их помощью. Как правило, речь идёт о JS-фреймворках, например:
Angular;
Vue.js;
Svelte;
React — формально это не фреймворк, а библиотека, но значение этого инструмента так велико, что его постоянно сравнивают с другими веб-фреймворками.
Фуллстек-фреймворки
Сюда относятся фреймворки, реализующие как клиентскую, так и серверную часть. Например, JS Meteor.
Возможности фреймворков
Веб-кеширование
Позволяет снизить нагрузку на сервер, отдавая самые популярные пользовательские данные из кэша.
Скаффолдинг
Позволяет автоматически сгенерировать наиболее важные части приложения или вообще, всю его структуру. Сильно повышает скорость разработки, очень полезно для новичков.
Шаблонизация
Отвечает за веб-публикацию. Основная задача шаблонизатора — отделить код от представления (например, HTML-разметки). Веб-шаблоны применяются для создания сайтов и страниц любого типа, так как шаблон выполняет роль незаполненного бланка документа, одинакового для любых представлений до заполнения данными.
Безопасность
Противостояние кулхацерам. Стандартизованные функции для идентификации пользовательских действий. Распознавание профилей, используемых для кликджекинга — механизма обмана, при котором злоумышленник получает доступ к конфиденциальной информации пользователя и даже его устройствам.
Сопоставление URL
Вообще, это механизм интерпретации URL-адресов. Нужно для упрощения индексации с сохранением красивого названия для сайта. Например, URL-адрес, который заканчивается на «/page.cgi?cat=science&topic=physics», можно изменить на просто «/page/science/physics», удобно и красиво же.
Приложения
Возможность разрабатывать стандартизованные приложения — форумы, блоги, CMS.
Важное для менеджера
На любом фреймворке можно реализовать как «летающий» продукт, так и медленно ползающее нечто, всё зависит от квалификации ваших разрабов и навыков архитектора. Поэтому фреймворк нужно выбирать не согласно веяниям моды, а исходя из того, каким лучше владеет ваш тимлид или CTO, это минимизирует риски.
Кроме того, специалисты, владеющие разными фреймворками, по-разному оплачиваются, есть более и менее оплачиваемые специализации. Эти цифры постоянно колеблются, никакой системы выделить нельзя, надо анализировать рынок в каждый момент времени.
В целом, это всё, что пиэму нужно знать о фреймворках.
С точки зрения классического менеджмента, худшее, что вы можете сделать — вырастить незаменимого сотрудника. Компания должна быть системой, в которой все элементы заменяемы. Но пока вы маленькие и компактные, никуда от этого не деться, обязательно выделятся лучшие сотрудники, соблазн поручать им всё больше и больше, слишком велик. Да и в целом, когда люди работают у вас относительно долго, скорее благо. Они лучше узнают все нюансы дела, прекрасно разбираются во внутренних процессах и проч. Очень больно, когда они всё же объявляют об уходе.
Любой сотрудник, с которым вы работаете, неважно, ваш подчинённый или руководитель, через какое-то время уволится, либо его уволят. Даже те, которые считаются столпами компании, рано или поздно свалят. Имеет смысл заранее проработать, что вы будете делать в этом случае.
Так как сделать, чтобы ключевые сотрудники не уходили как можно дольше?
Культура
Однажды уборщицу в офисе Аэрофлота спросили, почему она не уволится и не устроится на что-нибудь более денежное, а она ответила: «Вы что! Бросить авиацию?» Но ведь верно. Невозможно организовывать авиаперевозки из офиса с грязными полами, забитыми унитазами, заваленного мусором. Уборщица тоже в авиации, как и ведущий инженер, и гендиректор.
Есть мнение, что деньги — главное. Достаточно платить чуть выше рынка и всё будет хорошо. Это не совсем так.
Культура — штука сложная и многогранная. Сюда входит и доверие, и уважительное отношение руководства к сотрудникам, а также сотрудников друг к другу, и понимание, зачем существует компания, какие её основные цели, своевременная выплата зарплаты, отсутствие сокращений по желанию левой пятки директора, найм правильных людей. И практика показывает, что в компаниях, в которых есть хоть какая-то культура, сотрудники работают долго, даже если зарплаты ниже рынка.
Видение будущего
Люди охотнее работают в компаниях, в которых им показывают и рассказывают про их будущее, хотя бы раз в полгода. Каждый сотрудник, проработавший более-менее серьёзный срок, имеет карьерный трек, знает, чем будет заниматься через год и через пять, знает, каких результатов для этого ему надо достигнуть, какие обучения пройти, какие навыки подтянуть. Для грамотного специалиста это очень важно.
Соответственно, у компании есть стратегия на продолжительный срок, планы развития. Руководство понимает, на какие рынки собирается идти, какие продукты выпускать, как существующие продукты развивать, а также не стесняется на понятном языке доносить эту стратегию до сотрудников.
В общем, если уделять внимание этим двум аспектам, люди будут работать на вас дольше, чем в среднем по больнице. Не вечно, конечно, есть вещи вне контура вашего влияния, но долго.
Честно говоря, мне не нравятся формулировки новостей вида: «Илон Маск потерял за год 200 млрд. долл.» или «Безос потерял за один день 20 млрд. долл.» В голове сразу возникает картина, как со счетов миллиардеров списывают миллиарды или более архаичное, как большегрузные автомобили вывозят из их домов кубометры купюр. Конечно же, это не так.
На их счетах никогда не было этих миллиардов, у них просто были активы, которые кем-то были оценены по не пойми кем придуманным методикам в миллиарды и эта стоимость может меняться по первому чиху на Уолл Стрите. Ну и она качнулась в очередной раз. Мне кажется, об этом нужно писать менее желтушно.
* * *
О читабельности
Не то, чтобы я глубоко смыслил в написании кода, но одно знаю точно. У любого кода есть стоимость владения и чтобы она была минимальна, код должен быть в первую очередь написан не для машины, а для чтения человеком.
Читал пост одного френда (автоматизатор куа), которого на собесе спросили, как бы он решил задачу. В переменную передаётся строка, нужно определить, сколько в строке есть букв а, без использования готовых методов и библиотек.
Есть много способов. Можно, например, перебрать все буквы строки циклом и при нахождении а увеличивать счётчик на единицу. Можно удалить все буквы а, потом вычесть из длины исходной строки длину результирующей строки. Можно применить регулярку. Можно вообще, написать код на ассемблере, который сделает эту операцию супербыстро.
Мне кажется, хороший автоматизатор, да и разработчик, должен уметь делать любой из этих методов, но на практике реализовывать самый первый. Пусть код выполняется не очень быстро, зато когда этот сотрудник выгорит и уволится, не придётся искать днём с фонарём специалиста по ассемблеру или по регуляркам, который сможет разобраться, что там за код и что он делает.
Я же поддерживаю несколько сайтов на вордпрессе. И корректировки CSS темы делаю только при помощи инструмента дополнительного CSS, чтобы изменения не похерились при обновлении. И даже несмотря на то, что код там предельно простой и читаемый, всегда подписываю комментарий, для чего нужен каждый кусок, несмотря на то, что эти комментарии утяжеляют код и замедляют сайт.
* * *
О том, как важно не быть в балансе
Прочитал на vc перевод статьи предпринимателя, путешественника и писателя Криса Гильбо про 36 способов изменить жизнь. Заинтересовал пункт о том, что не надо быть в балансе:
5. Не пытайтесь «быть в балансе». Сбалансированные люди не меняют мир и никому особо не интересны. Будьте собой, принимайте взлёты и падения и просто живите.
Подумал, что профессия пиэма очень сильно способствует исполнению этого пункта. Я давно обратил внимание, что если моя работа становится размеренной, нет никаких пожаров и все просто спокойно работают, заливают фичи по расписанию, буквально через несколько месяцев меня уволят и заменят кем-то более дешёвым.
И это хорошо. Не даёт заскучать, всё время сталкиваешься с новыми вызовами, осваиваешь новые предметные области, изучаешь ранее неизвестные аспекты профессии.
* * *
О понимании классики
Carmina Burana — одно из важнейших классических произведений, вообще за всю историю музыки. В Википедии написано, что общий смысл у этой кантаты такой:
Композиционная структура во многом основана на идее вращения «Колеса Фортуны». Рисунок колеса был обнаружен на первой странице Codex Buranus. Он также содержал четыре надписи, помещённые на ободе колеса и в совокупности образующие стих: «Regnabo, Regno, Regnavi, Sum sine regno» (в переводе М. Л. Гаспарова — «Я воцарюсь — я царю — я царил — я ныне без царства»).
Во время каждой сцены, а иногда и во время одного действия, «Колесо Фортуны» поворачивается, счастье оборачивается печалью, а надежда сменяется горем. «O Fortuna», первая поэма в редакции Шмеллера, завершает круг, формируя остов композиции произведения.
А я услышал там немного другой, более приземлённый смысл. Кантата состоит из 24 музыкальных тем, начинается она, наверное, самой известной классической темой «O Fortuna». Она в глубоком миноре, текст — судьба ужасна и чудовищна, с самого рождения запущено колесо страданий бед и лишений, ничего с этим сделать нельзя.
Следующие композиции идут по нарастающей, доходя до 24 темы под названием «Ave formosissima», «Славься, прекраснейшая». Это такой светлый и радостный гимн. Так вот, в самом конце этой темы (не во всех исполнениях) звучит нечто, напоминающее механический будильник. Звук будильника становится всё громче и громче, перебивает весь оркестр, тема обрывается и снова звучит «O Fortuna», такое ощущение, что в два раза депрессивней и злее.
Я думаю, что кантата о убитом депрессией человеке, который случайно задремал, погрузился в мечты и этот сон был оборван будильником, после чего человек вернулся в свою депрессивную реальность. Такие дела.
* * *
О сантехнике и кораблях конвоя
У Розенбаума есть песня «Корабль конвоя». Она от лица корабля, который страдает из-за того, что хочет боёв и славы, а ему приходится сопровождать транспорты. И в конце ему говорят, что то, что транспорт дошёл, и есть его великая миссия и этим фактом он всё доказал, свою нужность и полезность.
Айтишникам свойственно хотеть работать над продуктами, которыми будут пользоваться миллионы пользователей, над условным Линкадином, ну или хотя бы Экселем. Но иногда ситуация складывается так, что становится необходимым заняться продуктом, который станет важным компонентом экосистемы, но единственным критерием его качества будет то, что овнеры соседних продуктов не прибегут и не закричат, что из-за вас у них всё сломалось.
Я называю это айтишной сантехникой. Заниматься айтишной сантехникой норм. Просто вы теперь корабль конвоя.
* * *
О нейминге
Конфузы нейминга во все поля. Придумали инструмент для управления проектами и оказалось, что в славянских языках это слово означают не то, что они имели в виду.
* * *
О маскирующихся убийцах
У меня было несколько постов о тихих убийцах, сегодня хочу немного рассказать о явном убийце, который иногда маскируется. Называется аппендицит.
В двух третях случаев он начинается разлитой болью в животе, которая через некоторое время концентрируется в правой подвздошной области. Повышается температура тела, тошнота и рвота, отсутствие аппетита, позывы к мочеиспусканиню, процесс болезненен, повышается температура тела. Боль усиливается при движениях, если лечь на правый бок, становится легче. Эти симптомы легко запомнить и распознать, при них нужно обязательно звонить в скорую. Причём, прекращение боли означает, что в аппендиксе умерли нервные окончания и он скоро прорвётся, звонить нужно уже срочно.
Но в одной трети случаев аппендицит маскируется под другие заболевания и не имеет конкретной картины симптомов. Определить, что у вас именно аппендицит, можно так. Лягте на спину и поднимите одну ногу, сначала правую, потом левую на 35-40 градусов. При аппендиците на эти движения будет резкая боль в боку. Если вы в полях и лечь некуда, резко кашляните, тоже будет резкая боль в боку.
* * *
О прошивании ПЗУ
Вы когда-нибудь задумывались о том, почему в отношении программирования ПЗУ говорят «прошить»? Оказывается, дело в том, что память раньше состояла из очень маленьких ферритовых колец, которые в буквальном смысле прошивали при помощи иголки проволочкой. Технология изменилась, а термин остался.
ПЗУ тех времён (постоянное запоминающее устройство с навечно еще на заводе прошитой информацией) делалось тоже на колечках, но размером куда как побольше и из «магнитомягкого» материала.
Колечек брали столько, скольки разрядное слово в этом ПЗУ; устанавливали их в один ряд; выходная катушка на каждое из них наматывалась многовитковая, а входных было столько, сколько слов информации надо было записать. Причем информация в буквальном смысле прошивалась: брали иголку, вдевали в неё проволочку для очередного слова и протягивали через весь ряд.
Причем если в данном разряде должна была быть единица — проволочку пропускали через кольцо, а если ноль — мимо. Потом, когда через эту проволочку пропускался импульс тока — в тех кольцах, сквозь которые она была продета, в выходной катушке наводится импульс напряжения. А в тех через которые нет, — импульса не было.
С появлением микросхем постоянных и полупостоянных запоминающих устройств больше так не делают. Но термин «прошить» по отношении к ПЗУ — так с тех времён и остался.
Из самиздатской книги «Фокал снаружи и изнутри»
* * *
О решении проблем
Мне кажется, что в бизнесе и в жизни, каждое нововведение должно в большей степени решать проблемы, чем создавать новые. Пример такого нововведения в моей жизни — купленные два года назад за 3700 ₽ часы CASIO AE-1000WD-1A. Было неудобно постоянно доставать смартфон, чтобы посмотреть время на улице. Кроме того, мне не хотелось покупать слишком дорогие часы, чтобы потом сдувать с них пылинки и переживать по поводу царапин. Купил вот эти и проблема решилась. Новых проблем не создалось вообще, батарейка рассчитана на 10 лет, раз в три года надо менять герметизирующую резинку, всё.
А вот с наушниками так не вышло. Я долгое время носил проводную гарнитуру и месяц назад решил идти в ногу с прогрессом, купив синезубую xiaomi buds 3 light за 1280 ₽. Дорогую решил пока не покупать, надо понять, будет ли удобно пользоваться. Я принял для себя, что получу ещё одно устройство, которое нужно заряжать.
Оказалось, что гарнитура прекрасно работает со смартфоном Xiaomi, достаточно сделать сопряжение и всё. Достал из чехла, они автоматом приконнектились, послушал, убрал, отконнектились. Проблема начинается, когда гарнитуру приходится использовать попеременно со смартфоном и макбуком. Даже если каждый раз руками отконнекчивать наушники от устройства, они далеко не всегда коннектятся с другим устройством, хотя заявлено, что должны тут же цеплять ближайший авторизованный девайс с включённым блютусом. Конечно, идеальным решением было бы купить эйрподсы, а к ним айфон (говорят, в яблочной экосистеме бесшовность потрясающая), но я по ряду причин не хочу айфон.
Кроме того, оказалось, что сенсорное управление на гарнитуре так себе. Где-то в одном случае из трёх, по двойному тапу происходит не переключение трека, а вызов голосового ассистента и остановка музыки секунд на десять. Видимо, это из-за того, что я одним движением нащупываю сенсорную поверхность, затем два раза тапаю, а устройство воспринимает это как тройной тап.
Проводная гарнитура несла в себе только две проблемы — провода и необходимость постоянно доставать смартфон. Беспроводная несёт множество проблем сразу. Такой себе прогресс, надо сказать. Но думаю, что всё равно, буду пользоваться. Может, потом куплю более дорогую.
* * *
Об анонимности
В середине нулевых мы обычно пользовались никами и псевдонимами. В ЖЖ даже был термин «девиртуализироваться», что означало встретиться с несколькими френдами в реале. У асечных друзей мы часто вообще не знали реальных имён. Я несколько лет переписывался с девушкой с ником Графиня де Графин и даже в голову не приходило интересоваться, как её звать на самом деле.
Но распространение соцсетей постепенно доломало этот тренд, настоятельно рекомендовав регистрироваться под реальным именем. Людям с никами даже какое-то время вешали обидные плашки. Постепенно общение от своего имени стало нормой. Не стопроцентной, конечно. У меня есть друг, работающий пограничником и так как это ведомство относится к ФСБ, ему аккаунт с реальным именем иметь нельзя, поэтому он во всех соцсетях под левой фамилией.
Это я к чему. Встретил в одном чате в телеграме человека с ником из нескольких эмодзи в виде стаканов с напитками. Человек писал довольно активно и чтобы не раздражаться, я добавил его в контакты, дав имя Дебилушка. Времена меняются.
* * *
О дефолтном состоянии ограничителей
В нормальных странах турникет метро всегда находится в закрытом состоянии и только если вы успешно оплатили поездку, открывается. И только у нас он по дефолту открыт и бьёт по ногам, если оплата не прошла. В российском вебе тоже так.
На мамбе вы можете выбрать девушку, долго ломать голову над первым сообщением, потому что на «привет, как дела» давно никто не отвечает, пишете и тут мамба сообщает, что девушка поставила ограничение по возрасту, в которое вы не проходите и надо купить VIP. Это аналог удара турникетом по ногам. Не надо так делать. Если пользователь не может выполнить действие, не надо разрешать ему его делать вообще.
* * *
О национальной идее
Мне же кажется, что русская национальная идея выражается концовкой анекдота: «Первый сломал, второй потерял». Эта мысль глубже и честнее.
Если я вижу сколько-нибудь интересную статью, обязательно сохраняю её в Эвернот. Делаю это с 2011 года. Потом разбираю сохранённое, присваиваю теги, распихиваю по блокнотам. Если надо найти одну из этих статей, достаточно вспомнить несколько ключевых слов и она найдётся сквозь года. У меня больше 22 000 таких статей.
И похоже, что мне придётся изменить этой привычке. Эвернот ушёл из РФ в первый же день СВО. У меня была мысль, что может быть, он против российских карточек. Попросил казахстанскую подружку дать мне данные казахстанской карты, оказалось, что их некуда вводить. При попытке обновить платёжные данные, сервис пишет, что не работает в моём регионе. У меня была мысль, что он определяет регион по айпишнику, поставил vpn, не помогло.
Пользоваться Эвернотом в привычном режиме с квотой в 60 мегабайт в месяц решительно невозможно. Этого места не хватало даже в 2011 году, во времена относительно лёгких страниц, сейчас же тем более. Видимо, зелёный слоник остаётся у меня теперь только в виде ретроспективной базы данных, дневников и квитанций за коммуналку, больше в него ничего не влезет.
Расчехлил OneNote, чо. Если не понравится, буду юзать Notion.
* * *
О специализации в резюме
Рекрутеры и карьерные коучи: По возможности, делайте специализированные резюме. Например, если вы разработчик и тестировщик, сделайте отдельное резюме на разработчика, отдельное на тестировщика.
Соискатели:
* * *
Об уходящих технологиях
Однажды вы в последний раз в жизни записали компакт-диск и даже представить не могли, что этот раз последний.
* * *
О сокращении товарных матриц
Мне кажется, что Яндекс заработает на подписке сильно больше, чем сейчас, если объединит все эти 360, 360 Бизнес, Плюс, Плюс Мульти и проч. в одну подписку под названием «Подписка на все сервисы Яндекса».
* * *
О совпадениях
Говорят, совпадений не существует. Но истинные джедаи знают, что совпадения случаются и порой очень причудливо. Год назад Олег Медведев отыграл четырёхчасовой онлайн-концерт в честь своего дня рождения, на котором между делом рассказал любопытный факт.
У него есть песня «Праздник», в которой есть строки:
Допустим, так: сходя с покатых холмов Китая, Таясь от взглядов любопытствующих селян, Перед границей остановишься, выжидая, Покуда солнце не закатится в гаолян. Чтобы никто не опознал тебя по приметам, Чтоб не поймали тебя угрюмые погранцы, Чтобы не выдало тебя солнце, сияя в медном Нагрудном знаке «За переправу через Янцзы».
Дело в том, что Олег Всеволодович никогда не изучал историю Китая и написал всё это из головы. И на одном концерте ему вручили в качестве сувенира… медный нагрудный знак «За переправу через Янцзы». Оказалось, этим событием завершилась одна из гражданских войн в Китае, это именно нагрудный знак и он медный.
Совпадения случаются.
* * *
Как бы я улучшил Яндекс.Еду
Постоянная рубрика «Как бы я улучшил…» Дело в том, что если заказывать в Яндекс.Еде еду из заведений, расположенных рядом с домом, стоимость доставки будет низкой, а скорость высокой. Но узнать о таких заведениях можно только методом тыка.
Добавить карту с заведениями, из которых доступна доставка по данному адресу. Тап по пину открывает стандартную карточку заведения. Делается за пару недель со всеми проверками.
Сейчас есть фильтр по времени доставки, но с картой было бы прикольнее.
* * *
О положительной мотивации
Смотрел вчера рилсы и на одном некая тётка говорила, что успешные мужчины у женщин, которые их хвалят. Периодически говорят, ты умный, ты успешный, ты толстый и красивый. Большинство старается соответствовать этим авансам и добивается успеха.
Мне кажется, совет работает и для подчинённых. Меня однажды представили как «нашего самого аккуратного и пунктуального менеджера» и я с тех пор не опоздал ни на одну встречу. Надо хвалить подчинённых, даже если они этого пока не вполне заслужили.
* * *
О боли
Есть только два гендера медработников хирургических специальностей:
Вы зачем приняли обезболивающее, картина симптомов же смазалась!
Вы почему не приняли обезболивающее и столько времени мучились, это же вредно!
* * *
О странных моментах в клиентоориентированности
В Кёниге никогда не было официального Apple Store. Зато есть премиум-реселлер i-center. В нём всё белое, стильные стойки для товаров, доброжелательные хипстеры-продавцы, у которых можно спросить что угодно про яблочные товары. За кулисами официальный сервис-центр.
В апреле прошлого года пришёл покупать новый макбук, потому что было полное ощущение, что если не купить его сейчас, другого варианта может не быть, а у моего ветерана вздулась батарея и отремонтировать его нельзя, даже за деньги, он устарел.
Пришёл, спрашиваю, а можно конкретно мой экземпляр посмотреть перед оплатой, мало ли брак. Хипстер-продавец говорит, брака у нас не бывает, а если и будет, сервис бесплатно всё отремонтирует. Отвечаю, что не хотелось бы сразу же отдавать новый комп в сервис, это некруто, хотелось бы заменить на нормальный. Он говорит, нет, деньги вперёд.
Может, сомневался, что у меня есть нужная сумма? Так мог бы попросить показать. Но всё вышло нормально, какого-либо брака за девять месяцев не вылезло.
* * *
О выражении чувств
В школьные времена один одноклассник дразнил меня за полноту «бочкой мёда», а я обижался. Прошло двадцать лет, эндокринолог запретила мне весь сахар, за исключением одной чайной ложки мёда в сутки. Пошёл покупать и обнаружил, что 330-граммовая баночка цветочного мёда стоит 264 рубля. А он — бочка. Наверное, чувак просто так по-детски неуклюже хотел сказать, что я ему очень дорог.
Штатный антрополог санитарного управления Нью-Йорка Робин Нейгл объясняет, почему современный человек боится собственного мусора и с неприязнью относится к людям, которые его за ним убирают.
После превращения нашего рынка труда в локальный, английский несколько утратил важность, но он остаётся актуальным для общения с представителями всяких Эритей.
Умещение сообщения в 70 символов, боязнь кнопки интернета и другие интернет-привычки, ушедшие в прошлое, но казалось, бывшие актуальны буквально вчера.
Бытует мнение, что тестовое на пиэма составить невозможно. Также есть мнение, что делать их не нужно. Однако, пока у вас мало опыта и недостаточно крутое портфолио, тестовое даёт возможность показать настоящие знания работодателю.
Дальше будут вопросы и задания из моих реальных попыток трудоустройства за последние восемь лет. Большинство ссылок на файлы работодателя уже не работают, к сожалению.
* * *
Исследовать, как на популярных сайтах и сервисах реализованы механизмы добавления контента в Избранное (Favorites). Рассмотреть процесс не с технической точки зрения, а с точки зрения удобства для пользователя.
По результатам исследования подготовить краткий отчет о текущих тенденциях в процессе добавления контента в Избранное (Favorites). В отчете привести ссылки, скриншоты и краткие характеристики с точки зрения usability для каждого рассматриваемого сайта.
Выбрать из проанализированных методов добавления контента в Избранное самый простой и удобный с точки зрения пользователя, обосновать выбор. Описать, как работает выбранный механизм в виде краткого описания всего процесса: что видит пользователь, какое поведение при добавлении в Избранное, при удалении из избранного, дополнительные подсказки, которые получает пользователь в данном процессе.
* * *
Вам нужно оценить проект, предполагающий как верстку, так и 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.5 календарных месяца, начиная с сегодняшнего дня.
Предварительная оценка на мобильный проект 400 на каждую платформу, 300 бэкенд.
Задачу сPower BIвыполняет сторонняя команда, но на нашей стороне необходимо готовить данные, предварительно это займет около 20 часов в неделю бэкенд разработчика.
На стороне клиента: менеджер проекта (работает непосредственно с вами), руководитель отдела и генеральный директор. Менеджер (клиента) проекта должен утверждать части выполненных работ и готовый продукт с руководителем отдела. Готовый продукт всегда утверждается у генерального директора, по прошлому опыту на это уходит около одной недели.
CTOподготовил для вас: 1 бэкенд разработчик, 1iOSразработчик, 1Androidразработчик, 1QA+ обещание передать любых разработчиков в течение 2-х недель после запроса. Так же у вас есть дизайнер, готовый работать фултайм.
На получение фидбека отQAи исправление багов уходит 2 недели.
Менеджер процессов подготовил для вас:1 аналитик и разрешил подключать других менеджеров проектов, если они свободны. В вашем отделе работают три менеджера. Они могут выполнять любые роли от аналитика до скрам-мастера. Кстати, по ощущениям аналитика, у него уйдет около 10 рабочих дней на весь проект.
СЕО сообщил: «Проект важный и вы можете мотивировать разработчиков бонусами, не более 20% от заработной платы в месяц»
Аккаунтпросит вас описать правила работы с Клиентом, обещает их продавить и согласовать, так как у Клиента горят сроки, и они согласны на любые адекватные условия.
Опишите, пожалуйста:
План А и План Б для разработки этого проекта простыми человеческими словами.
Общие риски проекта и план, если риски срабатывают.
Подготовьте упрощенные диаграммы Ганта для каждого плана, чтобы были видны все роли и общий таймлайн.
* * *
Часть 1
Уважаемый кандидат! В настоящем задании представлено краткое описание предполагаемой ситуации. Пожалуйста, проанализируйте её и ответьте на вопросы в письменном виде:
1. Что сделать менеджеру проекта?
2. Как ему избежать подобных проблем в будущем?
Описание предполагаемой ситуации
Последние два года Алексей трудился менеджером проекта в компании – системном интеграторе среднего размера. Причем все два года работал для одного крупного Заказчика. Для этого Заказчика был выполнен успешный проект по внедрению крупного централизованного комплекса управления информационной безопасностью, что обеспечило компанию постоянным притоком новых заказов на интеграцию с этим комплексом новых информационных систем, а также на расширение функциональности самого комплекса. Новые заказы поступали с частотой примерно 2 раза в месяц. И команда Алексея успешно с этим справлялась.
В команде работала пара технических лидеров – атомные ледоколы, которые, куда скажешь, туда и плывут. Настойчиво, целеустремленно и неутомимо. И было несколько стажеров и малоопытных специалистов.
Один из специалистов оказался способным сотрудником и быстро освоил новую для себя область знаний. Многие из рутинных задач он научился выполнять в минимальные сроки за счет эффективного использования наработок и частичной автоматизации.
Алексей, видя активность в работе специалиста, а также его отдачу в проекте, понимал, что надо парня двигать вперед. Но как это делать, Алексей не понимал. Точнее, не было времени. Новую функциональность надо было выпускать каждый месяц, а это требовало пристального внимания руководителя. Кроме этого, команда укладывалась в сроки только благодаря наработкам этого специалиста. Алексей понимал, что переведи он ценного специалиста на другой проект, он гарантированно не сможет обеспечить выполнение обязательств по уже заключенным компанией договорам с данным ключевым Заказчиком. «Но делать с парнем что-то надо, – думал Алексей, – рано или поздно ему все это надоест».
И действительно, две недели назад, упомянутый специалист подошел в конце рабочего дня и спросил: «Алексей, а как бы мне сменить характер работы? А то я тут уже все изучил, сделал все, что мог…». Алексей понял, что надо что-то решать, и пообещал специалисту, что со следующего проекта переключит его на новую деятельность.
Обнадеженный специалист ушел, и Алексей вернулся к тушению очередного пожара в очередном проекте. Прошло десять дней, и Алексей внезапно вспомнил, что специалиста было обещано перевести на другой проект. Однако тут возникли проблемы. Изначально Алексей предполагал, что на текущие проекты бросит двух стажеров. Но те встали в глухую оборону, заявляя, что в обозначенные сроки они со своим уровнем знаний выполнить поставленную задачу точно не смогут. А тут еще и Заказчик решил, что ближайший релиз нового функционала ему нужен через месяц, а не через полтора, как этого предполагал изначальный план проекта. Заказчик для компании интегратора является стратегическим. Не идти навстречу Заказчику нельзя. Стало понятно, что если заменить текущего специалиста в проекте на стажеров, то качество продукта в значительной степени просядет.
До встречи со специалистом, на которой Алексей должен был объявить ему о новой работе, оставался еще час. Нужно было что-то придумать.
Часть 2
Данная задача предполагает составление плана в любом удобном для вас инструменте. В случае необходимости сопровождения плана комментариями необходимо приложить текстовый документ.
Описание предполагаемой ситуации
Вы руководите проектом по разработке новой информационной системы, используя Scrum. В вашей команде 2 разработчика (Алексей и Михаил), аналитик (Елена) и тестировщик (Артем). Вам необходимо составить план работ на первую 2х недельную итерацию, основываясь на оценках, которые вам сообщает команда.
Задача
Оценка от команды
Задача 1
Алексей: в целом задача ясна и мне будет скорее всего достаточно 16 часов на ее реализацию, если не будет проблем. Елена: учитывай, что на уровне БД скорее всего буду проблемы с написание процедур Алексей: ну если так, то можно еще 7 часов добавить на решение возможных проблем, но это максимум. Скорее всего я все решу за 20 часов.
Задача 2
Михаил: делал аналогичную задачу в прошлом проекте с тем же стеком. Хватило 7 часов на реализацию
Задача 3
Елена: Тут сначала мне нужно спроектировать логику работы. Задача большая часов на 40. Да и нужно в процессе пообщаться будет с Михаилом, отвлечь его часов на 6. И не забывайте, что я буду в отпуске 2 дня где-то в середине выполнения данной задачи.
Задача 4
Артем: мне на тестирование каждой выполненной задачи понадобится 2 дня. Это с учетом составления протокола
При составлении плана стоит учесть, что задачи 1 и 2 могут выполняться параллельно, а задача 3 может зависит от выполнения задачи 2.
Подумайте над рисками, которые бы вы заложили в план итерации. Какие вопросы вы бы задали команде в реальной ситуации?
* * *
Вы поставили программисту задачу: «Заменить все ссылки на сайте — на фиолетовые». От программиста поступил ответ: «Мне кажется, фиолетовый — это цвет самоубийц. Поменял на серые. Так круче!».
Какие цели и интересы преследовал программист?
Какие цели и интересы у менеджера в данной ситуации?
Описать свои действия в такой ситуации, аргументировать их.
* * *
Зачем команде разработки нужен менеджер?
Кейс 1
Вы будете заниматься редизайном платформы IT-волонтёр. У вас в команде будет product owner, UX-дизайнер и три fullstack-разработчика. Команда распределённая. Основные цели редизайна:
Повысить вовлечённость волонтёров
Увеличить число решаемых задач
Сделать дизайн более современным
Не позднее 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 по каждому проекту за все дни.
Вам необходимо скачать файл “Тестовое задание на знание Excel” и переслать его обратно с готовым решением.
* * *
Кейс #1
Команда работает по двухнедельным спринтам. По окончанию итерации происходит релиз.
В конце спринта команда понимает, что не успевает выполнить задачи, которые влияют на достижение цели текущего спринта.
Как следует поступить с текущим спринтом?
Как предусмотреть возникновение аналогичной ситуации в будущем? В рамках каких событий и с кем будет происходить поиск решения?
Существуют ли критерии готовности историй для релиза? Какие? Кто их генерирует? Кто контролирует и принимает решение о готовности спринта к релизу?
Кейс #2
Для Data Science команды опишите процесс работы с гипотезами данных, этапы процесса, критерии прохождения каждого этапа.
Кейс #3
Приведите примеры метрик, которые описывают эффективность процесса разработки. Для 1-2 метрик опишите, как их можно измерять и с помощью каких инструментов
Кейс#4
Опишите отличия методологии Скрам от методологии Канбан. Как выбрать более подходящую для команды методологию?
В изрядной доле проектов нужно интегрировать два или больше приложений. В самом тривиальном случае — фронтенд с бэкендом. В более сложном — мобильное приложение с бэкендом. В случае со звёздочкой — два бэкенда и другие извращения. Стандартом де-факто для таких задач в наше время считается API.
Кроме того, в вашем продукте может потребоваться реализовать дорогостоящую функцию, которая уже сделана в стороннем сервисе на отличненько. Например, если вам нужны карты, целесообразно использовать API Open Street Map или Яндекс.Карт, это сильно дешевле, чем пилить собственные карты.
Также вам пригодится API платёжных шлюзов, если нужно реализовать на сайте оплату чего-нибудь, неважно, физических товаров или виртуальных.
В наше время считается дурным тоном делать регистрацию и авторизацию на сайте логином и паролем, это делают через API социальных сетей, гугловский, фейсбучий, вконтактовский, телеграмовский.
Если у вас сайт с большим количеством контента, например, маркетплейс, имеет смысл реализовать API для использования ваших данных в сторонних сервисах (возможно, платно), это проще, чем постоянно банить десятки ботов, которые будут ваши данные парсить, создавая нагрузку на сервера.
Самая прозрачная аналогия с реальным миром — ресторан. Кухня — бэк, зал ресторана — фронт, официанты — API. Посетитель через зал посетителей стучится в API-официанта, даёт ему заказ. Официант доставляет заказ кухне-бэкенду, там его готовят и отдают официанту, который доставляет результат клиенту в зал ресторана. Если всё сильно упростить, реальное API работает именно так.
Различия REST и SOAP
Чаще всего в современной разработке встречаются REST и SOAP API. Давайте разберём, в чём разница.
REST
REST(от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.
Предполагает использование протокола HTTP для передачи данных.
Применяется преимущественно в вебе и в мобильных приложениях.
Ещё используется в облачных вычислениях.
Через REST API могут передаваться разные форматы данных, но обычно используется JSON.
Предполагает кэширование передаваемых данных.
Хорошо масштабируется.
SOAP
SOAP(от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC).
При помощи SOAP данные могут передаваться не только через HTTP, но и, например, MQ.
Применяется, преимущественно, в Enterprise, для интеграции нескольких отдельно стоящих систем.
Данные передаются только в формате XML.
Данные не кэшируются.
Типы запросов
Метод обозначает тип производимого запроса, де-факто он является спецификацией операции, которую должен произвести сервер. Всего существует пять типов запросов:
GET
POST
PUT
PATCH
DELETE
GET – используется для получения со стороны севера определенного ресурса. Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.
POST – нужен для создания определенного ресурса на сервере. Сервер создает в базе данных новую сущность и оповещает вас, был ли процесс создания успешным. По сути, это операция создания.
PUT и PATCH – используются для обновления определенной информации на сервере. В таком случае сервер просто изменяет информацию существующих сущностей в базе данных и оповещает об успехе выполнения операции.
DELETE – как и следует из названия, удаляет указанную сущность из базы или сигнализирует об ошибке, если такой сущности в базе не было.
Postman
Для тестирования API применяется инструмент Postman. Раньше он был плагином для Хрома, но сейчас это автономное приложение для любых платформ. Штуковина достаточно понятная интуитивно, разработчики чаще всего передают данные об API тестировщикам именно в виде коллекций Постман.
Эндпоинт принимает только один строковый параметр text. Отправим Постманом GET запрос на этот эндпоинт:
Интерфейс Postman с простым GET-запросом к API
Как видите, 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:
