Как подготовить ТЗ разработчику, чтобы не получить кота в мешке

Я встречала разработчиков, которым можно сумбурно накидать идей off top of my head - и они сделают четко то, что ожидалось… пару раз за всю мою карьеру.

Так что, чтобы впоследствии не плясать с бубном, объясняя клиентам/инвесторам/маме как работает ваш продукт, готовьте ТЗ. Рассказываю как.

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

❤️Определите пользователей - кто они, сколько их и где они обитают 🔎 какие паттерны взаимодействия с приложением: его открывают раз в неделю в рабочие часы или юзают дненощно? Нужна ли ролевая модель?

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

❤️Не забудьте о нефункциональных требованиях - на каких устройствах / с каким разрешением UI должен корректно отображаться? В каких браузерах? Какой трафик сервис должен выдерживать и как быстро отвечать пользователю? Какие данные хранить и в течение какого срока?…

❤️Зафиксируйте основной стек - языки программирования, фреймворки, тулзы и движок сайта, проверьте, нужны ли вам на что-то корпоративные лицензии.

❤️Опишите зависимости - круто, если вы планируете запускать приложение в вакууме, но куда вероятнее, что данные нужно будет тянуть из корпоративной базы, отчеты складывать в хранилище, да и вообще интегрироваться со сторонними сервисами. Чтобы не страшиться интеграционных тестов, приложите нужные API и схемы к ТЗ.

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

❤️Проясните Definition of Done - какие будут критерии «сделанной работы». Разработчик вам отправит сборку? Или развернет приложение на вашей среде, прогонит все тесты, а еще будет рулить rollout-ом на всех юзеров?

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

Теперь вы знаете как делать мощное ТЗ 🚀

А если вам не терпится применить навыки на практике, делюсь контактом Димы.

Дима - fullstack программист с широким стеком и таким же обширным опытом разработки проектов разного формата. Сейчас он запустил предложение по разработке MVP за 7 дней по очень хорошему прайсу. Так что если у вас давно есть идеи, но некому их воплотить в жизнь, напишите Диме - он подскажет, что можно сделать.

А как вы взаимодействуете с разработчиками? Формулируете требования в ТЗ?

Уже год я не рассказываю, чем занимаюсь

Такой фидбэк я получила от подписчиков. И правда, уже ровно год, как я приняла оффер от Delivery Hero и релоцировалась в Берлин, а упоминала об этом пока лишь вскользь. Исправляюсь.

Кто я и чем занимаюсь?

Я - Катя, backend разработчик со стеком Java/Kotlin и плотным вовлечением в DevOps. Мой основной фокус - проектирование и разработка высоконагруженных приложений, которые способны обрабатывать big data в real-time, и выдерживать по 1+ млрд запросов в день (RPD).

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

Чтобы прийти к этой точке, я получила магистерскую степень в «инженерии и анализе данных» в TUM - топ-10 универе в мире в сфере CS 🎓 А еще проектировала big data сервисы с day 1 моей работы в ИТ - сперва в ритейле в РФ, а затем в cybersec-e и e-commerce в Германии.

Так что там с оффером от DH?

Delivery Hero - один из крупнейших в мире сервисов доставки еды (такая себе смесь Яндекс Лавки и Еды). DH оперирует в 70+ странах в 4-х регионах - LATAM, EU, MENA, APAC и принимает daily заказов больше, чем Amazon.

Но не спешите искать приложение DH в App Store - его там нет 🙃 У DH 11 брендов, под которыми компания оперирует на локальных рынках, например, в ОАЭ это Talabat, в Азии Foodpanda, в Восточной Европе - Glovo.

А вот в Германии DH не работает, несмотря на то, что в Берлине находится HQ 😐 Что же мы здесь делаем? Разрабатываем центральные сервисы, на которые идет трафик со всего мира 🌎

И здесь включаюсь я 👋 со своими ночными дежурствами и инцидентами в 03:00 в Азии 😭

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

Самый кринжовый фейл при трудоустройстве ever

…или как собес на английском застал меня врасплох. Ситуация, которую меньше всего ожидаешь после 4-х лет работы за рубежом, десятков собеседований и теста IELTS, который я сдала на С1 🙂

«Как этот hell мог произойти?» - спросите вы. Рассказываю 🤓

Начиналось все ровно - созвон с эйчаром из fintech-единорога прямиком из GCC. Обсудили мой опыт, прошлись по вопросам по резюме (HR сказал, что резюме - вообще top out of the top, и я похожа на того, кто им и нужен), перешли к дальнейшим шагам.

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

Вскоре приходит ссылка на тест на платформе TestGorilla. Дается 10 минут и порядка 15-20 вопросов, где нужно выбрать один правильный ответ по абзацу текста.

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

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

Судорожно тыкать наугад - как-то не гордо, не вписывается в картину того, как я вижу себя в свои 25+. Так что открываю гугл и под прицелом вебки (она записывает для верификации, что мне никто не помогает), гуглю незнакомые слова…

Три минуты до конца теста, а я только на шестом вопросе. Математика не сошлась 🐶 Становится ясно, что таки придется судорожно тыкать наугад.

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

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

А пока делюсь контактом Агаты - она уже 7+ лет строит успешную карьеру project менеджера🌟Свой обширный опыт в IT Агата вместе с экспертами в сфере образования собрала и оформила в курс английского для айтишников - там собраны все ключевые темы, которые помогут уверенно ощущать себя на собесах.

А вы уже пробовали проходить интервью на английском? С какими сложностями сталкивались?

Для меня не профитная, но по многочисленным запросам

Реклама. Захарова Агата Александровна, ИНН 600801161800

Как ловить прод, если он падает - ч.2

Сейчас сижу, пишу отчет по новому инциденту (IR - incident report) 😬 и думаю, что самое время закрыть тему, которую мы уже начинали обсуждать в этом посте.

Тогда я рассказывала о том, как готовиться к инцидентам в ИТ сервисах (н-р «пользователи не могут залогиниться», «курьерам не показываются новые заказы в приложении» или же просто «запросы стали обрабатываться недопустимо долго»).

Сейчас обсудим, как действовать во время - куда бежать, что делать, и как при этом не чувствовать себя 🐶

Итак, вам пришло уведомление о том, что что-то не работает.

1️⃣После того, как вы подтвердили получение уведомления, проверьте источник - если его вручную создала операционная команда, свяжитесь с ними за деталями. Также, они помогут оценить ущерб и blast radius - согласитесь, "ухудшился пользовательский опыт" для 0.001% пользователей и "отпал целый регион" - совсем разные проблемы, и реагирование будет отличаться.

Часто есть позыв пропустить этот этап, но так не надо.

Мы так как-то решили, что проблема не критична и ушли в воскресенье отдыхать. Как итог - продолжительность инцидента 31 час и десятки тысяч $ потерь обнаруженных постфактум 🙄

2️⃣С поправкой на потенциальный ущерб определите состояние приложения, обычно выделяют:
- operational (работает)
- degraded performance (опыт пользователя ухудшен, но основные сценарии работают)
- partial outage (часть важного функционала отпала)
- major/full outage (все очень плохо)

Эскалируйте инцидент согласно вашей оценке.

3️⃣Локализуйте проблему - постарайтесь определить, в вашем ли она сервисе, если есть подозрение, что нет, добавьте соответствующие команды как responder-ов, чтобы они подключились и проверили свои зоны ответственности.

4️⃣Сфокусируйтесь на том, чтобы "оживить прод" (англ. to stop bleeding) - проверьте, какие были последние изменения, имеет ли смысл их откатить и т.д. Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена.

5️⃣Если все вроде разрешилось - продолжайте мониторить и составьте postmortem (он может выглядеть как тот incident report, который я сегодня пишу):
❤️оцените точный ущерб,
❤️проанализируйте, почему же так произошло (мы используем технику 5-whys),
❤️опишите action-поинты и в какие сроки они должны быть закрыты.

6️⃣Мы презентуем эти отчеты на еженедельной встрече, где можно эскалировать менеджменту какие-то action point-ы при необходимости.

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

Что еще почитать по теме?
- DH Reliability Manifesto
- Создание SRE культуры чтобы предотвратить потерю 12mln $
- Как Ozon работает с упавшим продом

Расскажите, вам доводилось быть участником/наблюдателем/сочувствующим на инциденте?

Тем временем, на канале новая аватарка, не теряйтесь 👋

Как вывезти конфликты и переговоры и выйти из них победителем?

Вчера прошло завершающее занятие курса по коммуникации, ради которого я вставала в пущую рань по субботам вот уже 3 месяца 😬 (но я сама вызвалась в это время, так что не пристало жаловаться 🤪)

Курс вел Марат Айрапетян, преподаватель по переговорам в ВШЭ и Сколково, а еще космический инженер с 5-летним опытом работы в Роскосмосе. С Маратом я познакомилась еще 2 года назад и тогда меня поразила история с одного из его публичных выступлений.

Вот представьте, полный зал на 200+ человек, все смотрят на вас. Вы выступаете с темой, которую старательно готовили. И тут выкрик из зала:

Ну какой же бред! А вы точно эксперт в теме?

Ваша реакция? Игнорировать выкрик? Съязвить? Начать оправдываться?

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

Курс был объемный, инсайтов море. Делюсь некоторыми из них:

1️⃣ Конфликты и переговоры - это не поле боя, где соперник унижен 😁, а победителю все лавры. Наоборот, это про сотрудничество, где идеальный итог - когда каждый достиг своей цели (win-win), и вы сохранили отношения.

2️⃣ Работа с эмоциями собеседника - первый этап любого конфликта. Невозможно переходить к рациональным аргументам и вообще стараться о чем-то договориться, пока человек еще находится в «эмоциональной плоскости».

3️⃣ При отстаивании своих границ важно соблюдать итеративность, т.е. постепенно переходить по следующим стадиям защиты:

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

Важно дать человеку право на ошибку и возможность ее исправить.

4️⃣ По сути, конфликт - это нападение на границы или социальную роль.

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

Если подобную нападку не обработать и не «выровнять свою роль», то она может закрепиться и к вам начнут относиться именно так 😐

Поэтому важно отслеживать изменение соц. ролей в моменте и уметь их восстанавливать.

5️⃣ Для успешных переговоров важно выяснять «картину мира» собеседника - какой у него взгляд на проблему, цели, вводные…

Иначе вы будете как 😶 тыкаться наугад, что уж точно не укрепит вашу позицию.

Это можно сделать задавая вопросы. Причем, и для выяснения («как ты на это смотришь?»), и для верификации («я правильно поняла, что для тебя наиболее важно то и то?»).

6️⃣ Итеративность важно так же соблюдать и в переговорах. Не нужно пытаться закинуть сразу все 3-5-6 вопросов, которые вы хотите обсудить, потому что собеседник сразу зацепится за тот, который наиболее удобен ему.

Лучше идти поочередно, начиная с самого важного. Когда пришли к соглашению по нему - переходите к следующему.

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

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

8️⃣В переговорах важно держать в голове «точку 0» - что будет, если мы не договоримся. Это поможет в ситуации, когда вас пытаются продавить на невыгодные вам условия.

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

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

А у вас возникали сложные или конфликтные ситуации на работе? Как вы с ними справлялись?

Куда делись все проджекты в Big Tech-e?

В далекие времена моей работы в аутсорсе, мне казалось, что роль project-а не заменима. Ведь кто еще бы смог менеджить весь цикл проекта - от kick-off встречи с заказчиком до приемки-сдачи, прорываясь через горящие дедлайны и утрясая конфликты в команде, у которой тоже от всего периодически пригорает?

Затем я перешла в продуктовую разработку и сменив 3 компании в Big Tech-e, я так и не встретила ни одного project-а. Такой роли у нас попросту нет. Куда же она делась? Разделилась и трансформировалась в:

❤️ «трушных проджектов» - этих ребят я искала днем с огнем и нашла в отдельном департаменте, с которым мы лишь изредка пересекаемся. Они планируют и запускают проекты с 0 до MVP/MLP, а дальнейшее развитие продукта передают уже в руки delivery manager-ов (они же - engineering manager-ы).

❤️delivery manager-ов - вот они уже day-to-day менеджат команду разработки, приоритизируют задачи, находят нужные ресурсы, убирают блокеры - в общем делают все для масштабирования продукта.

В чем плюсы такой трансформации и как стать успешным delivery-manager-ом - можете узнать в интервью с Артемом Арюткиным. Артем - директор по технологическому развитию в Сбере и на своем канале он рассказывает о том, как резал монолит СБОЛ, повышал надежность платформы для масштабирования с 10 до 79 MAU, и как строит эффективные процессы и команды. Рекомендую подписаться, если вам так же как и мне интересна тема delivery-management-а.

А у вас в компании есть проджекты? Какая у них зона ответственности?

Fight or flight в офисе

Как часто наши неосознанные реакции, рефлексы и эмоции, эволюционно призванные нас защитить, мешают жить той жизнью, которой мы хотим.

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

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

Хорошая новость состоит в том, что этот порочный круг можно разорвать. И первый шаг к этому - начать отслеживать свои реакции. Мне нравится терминология «бей или беги» (или «замри»), введенная Уолтером Кенноном для описания реакций на стресс. Причем, часто у человека превалирует одна из них.

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

Я же за собой куда чаще замечаю «замри» (до онемения в теле и зажима в горле) или «беги» - когда на работе все пригорает, я отвожу душу просматривая вакансии в LinkedIn Jobs или ищу как выйти в окно отпуск ASAP. Так и получилось, что я сбегаю на уикенд в Париж 😅 Жду посадку, предвкушаю свежий круассан на завтрак и радуюсь, что моя работа таки дает возможность вот так спонтанно от нее уехать 😄

Пока я отдыхаю и практикую slow posting, хочу поделиться своими любимыми каналами девушек-айтишниц, сама я вдохновляюсь их опытом развития карьеры в разработке и продукте, и узнаю, как зарешивать различные вопросы так, чтобы стрессовать не пришлось 🤝

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

А как вы реагируете на стресс? И как преодолеваете его?

Как управляют в ИТ? ч.1

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

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

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

Тем не менее, этот стиль лучше всего себя показывает в ситуациях:
❤️горящих дедлайнов - когда нет времени мусолить альтернативные идеи, надо делать.
❤️на фабриках - когда есть четкая технология и меры по технике безопасности.
❤️с junior-коллегами - неопределенность в сложных задачах их может пугать и только демотивировать, а вот понятные инструкции дадут +100 к уверенности в своих силах.
❤️в критичных ситуациях - когда нужно быстро принимать решения, которые вне компетенции рядовых сотрудников.

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

Звучит бомбически, не правда? А в чем подвох? Для недирективного управления нужны предпосылки:
❤️мотивация сотрудника - если он не хочет развиваться и брать ответственность, то с него уж взятки гладки 💍
❤️безопасная среда - если каждое смелое предложение менеджменту - это «игра на вылет» или в целом токсины in the air, проявлять инициативу вряд ли захочется.
❤️фокус на сотруднике - его цели, стремления, как он сам видит свое развитие? Используются коучинговые методики, когда менеджер, задавая правильные вопросы, помогает сотруднику самому прийти к решению.
❤️обоюдная готовность к переменам - развитие команды требует сил и времени, к чему любой из участников может не быть готов в данный момент.

Как думаете, какой стиль управления превалирует в ИТ и почему?