Я тебя услышал
Знаете, когда говорят "я тебя услышал" в значении "я понял твое мнение и мне на него наплевать"? В английском тоже есть подобного рода ехидные фразочки. Вот их расшифровка:
As per my last email = In case you didn't fucking read what I wrote before;
To reiterate = I'm not fucking saying it again;
Thank you for your input = No one fucking asked you;
Moving forward = That was the last time this shit came over;
As a kindly reminder = In case you fucking forgot;
Hope this email finds you well = Honestly, don't give a fuck about your life;
How can I help you to solve it? = This takes too fucking long. Solve it fast, I don't care how;
Best regards = тут либо fuck you, либо wish you the best, как повезет;
Знаете, когда говорят "я тебя услышал" в значении "я понял твое мнение и мне на него наплевать"? В английском тоже есть подобного рода ехидные фразочки. Вот их расшифровка:
As per my last email = In case you didn't fucking read what I wrote before;
To reiterate = I'm not fucking saying it again;
Thank you for your input = No one fucking asked you;
Moving forward = That was the last time this shit came over;
As a kindly reminder = In case you fucking forgot;
Hope this email finds you well = Honestly, don't give a fuck about your life;
How can I help you to solve it? = This takes too fucking long. Solve it fast, I don't care how;
Best regards = тут либо fuck you, либо wish you the best, как повезет;
Как держать беклог чистым
В тайм менеджмент есть такое правило двух минут. Если ответить на письмо занимает 2 минуты и меньше, то сделай это сразу, не откладывай в долгий ящик. Тогда инбокс будет пустой. И даже как-то немного приятнее станет работать, как когда порядок на столе.
Аналогичное правило можно применить и для беклога. У нас в команде оно звучит так:
❗❗ Если задача занимает меньше получаса, то делай ее сразу, не заноси в беклог.
Это дешевле, чем каждый раз спотыкаться об нее, пролистывая список задач.
К тому же экономится время на фокусе и контексте. Пока разработчик работает над фичей, ее устройство у него в "оперативной памяти". Правочки вылетают из Xcode, как горячие пирожки.
Когда он переходит на другую фичу, то подробности первой из памяти удаляются. Чтобы через месяц вернуться и что-то в ней доделать, придется вспоминать, как этот код работает. На это уйдет немного лишнего времени, поэтому лучше сразу.
В тайм менеджмент есть такое правило двух минут. Если ответить на письмо занимает 2 минуты и меньше, то сделай это сразу, не откладывай в долгий ящик. Тогда инбокс будет пустой. И даже как-то немного приятнее станет работать, как когда порядок на столе.
Аналогичное правило можно применить и для беклога. У нас в команде оно звучит так:
❗❗ Если задача занимает меньше получаса, то делай ее сразу, не заноси в беклог.
Это дешевле, чем каждый раз спотыкаться об нее, пролистывая список задач.
К тому же экономится время на фокусе и контексте. Пока разработчик работает над фичей, ее устройство у него в "оперативной памяти". Правочки вылетают из Xcode, как горячие пирожки.
Когда он переходит на другую фичу, то подробности первой из памяти удаляются. Чтобы через месяц вернуться и что-то в ней доделать, придется вспоминать, как этот код работает. На это уйдет немного лишнего времени, поэтому лучше сразу.
Еще один приемчик:
❗❗ Заводи все корнер кейсы, очень редкие баги, таски, которые хорошо бы когда-нибудь сделать, но прямо щас давайте отложим в отдельный проект.
Тоже чтобы не болтались под ногами и не раздували беклог. Смысл в том, что если их сейчас не стыдно отложить, то 99% что до них уже никогда не доберутся.
У нас такой список называется "Postponed bugs". В нем около 30 задач, в то время как во всем беклоге в районе 150.
❗❗ Заводи все корнер кейсы, очень редкие баги, таски, которые хорошо бы когда-нибудь сделать, но прямо щас давайте отложим в отдельный проект.
Тоже чтобы не болтались под ногами и не раздували беклог. Смысл в том, что если их сейчас не стыдно отложить, то 99% что до них уже никогда не доберутся.
У нас такой список называется "Postponed bugs". В нем около 30 задач, в то время как во всем беклоге в районе 150.
Лайфхаки в SaaS
На текущей работе я отвечаю в том числе за поддержку клиентов. Поэтому не могу пройти мимо круто построенного пользовательского опыта.
--------------------------------------
Зашел недавно на hotjar.com в поисках тулы для пользовательских интервью. За 30 сек не понял, решит сайт мою проблему или нет, и пошел спрашивать в саппорт. Здесь меня ждал сюрприз.
Сервис предлагает два варианта:
- "Написать в поддержку (среднее время ответа 1-2 бизнес дня)" или
- "Узнать в центре знаний (6-7 минут)"
Трюк здесь в том, что у всех SaaS есть и поддержка, и центр знаний (это обычный FAQ). И все отвечают примерно за 2 дня. Но hotjar с помощью трех слов о скорости ответа сделал второй вариант очевидно более привлекательным. В него будут чаще конвертиться, и меньше писать в саппорт. С такой формулировкой даже лентяй вроде меня задумается, стоит ли ждать 2 дня, если можно получить ответ почти сразу, поискав на сайте.
👍 Лайк!
На это еще не все. Жму "написать в поддержку", описываю свой юзкейс. И тут сбоку всплывают превью статей из того же FAQ, на основе ключевых слов моего запроса. То есть, когда, казалось бы, я уже ушел в поддержку, все еще есть шанс сконвертить меня в FAQ.
И это настолько естественно и ненавязчиво, что выглядит как забота о моем времени, хотя по факту ребята пытаются сэкономить на своих костах поддержки.
👍👍 Суперлайк!
На текущей работе я отвечаю в том числе за поддержку клиентов. Поэтому не могу пройти мимо круто построенного пользовательского опыта.
--------------------------------------
Зашел недавно на hotjar.com в поисках тулы для пользовательских интервью. За 30 сек не понял, решит сайт мою проблему или нет, и пошел спрашивать в саппорт. Здесь меня ждал сюрприз.
Сервис предлагает два варианта:
- "Написать в поддержку (среднее время ответа 1-2 бизнес дня)" или
- "Узнать в центре знаний (6-7 минут)"
Трюк здесь в том, что у всех SaaS есть и поддержка, и центр знаний (это обычный FAQ). И все отвечают примерно за 2 дня. Но hotjar с помощью трех слов о скорости ответа сделал второй вариант очевидно более привлекательным. В него будут чаще конвертиться, и меньше писать в саппорт. С такой формулировкой даже лентяй вроде меня задумается, стоит ли ждать 2 дня, если можно получить ответ почти сразу, поискав на сайте.
👍 Лайк!
На это еще не все. Жму "написать в поддержку", описываю свой юзкейс. И тут сбоку всплывают превью статей из того же FAQ, на основе ключевых слов моего запроса. То есть, когда, казалось бы, я уже ушел в поддержку, все еще есть шанс сконвертить меня в FAQ.
И это настолько естественно и ненавязчиво, что выглядит как забота о моем времени, хотя по факту ребята пытаются сэкономить на своих костах поддержки.
👍👍 Суперлайк!
Стадии развития команды
Психолог Брюс Такман предложил модель развития команды, которая хорошо ложится на наш ИТ мир. Менеджеры любят к ней апелировать и спрашивать на собеседованиях. Она несложная, убедитесь сами:
❗❗ Каждая команда с первого дня пройдет 4 стадии роста: forming, storming, norming, performing.
Давайте рассмотрим каждую из них.
👋 Forming
На первой стадии все учтивы и доброжелательны, присматриваются друг к другу. Конфликтов избегают. Людям хочется произвести хорошее впечатление, поэтому они работают чуть лучше и больше обычного. Для менеджера это главное время зарабатывать авторитет и устанавливать границы что можно, а что нельзя.
🖕 Storming
Игра престолов начинается здесь. Люди поняли, кто чего стоит и потихоньку начинают разыгрывать локальные войнушки.
Кто-то уйдет: "в гробу я видал такого тимлида!".
Кто-то отмалчивается: "сами как-нибудь разберутся, зп капает и ОК".
Кто-то проталкивает свои идеи: "я в прошлой компании писал на vue.js, проект взлетел, давайте и тут все перепишем".
На производительности это сказывается плохо, из-за споров и разногласий работа делается долго.
🤝 Norming
Рано или поздно, народ устает выяснять отношения и кто-то вспоминает, что пришел сюда решать задачи. Люди потихоньку начинают слушать друг друга, договариваться, искать компромисс. Появляются ростки доверия и эмпатия. Как следствие, растет скорость закрытия задач.
На этой стадии ПМ уже задумывается о делегировании.
💪 Performing
На ретроспективе все чаще слышно "у нас сильная команда, все друг другу помогают". Шишки набиты, ответственность распределена, все знают что и как работать. Уйти в отпуск на 3 недели не проблема. Функция менеджера тут поддерживающая. Без него не обойтись только во внештатных и критических ситуациях.
Вот и все, теперь вы знаете модель Такмана.
--------------------------------
Картинка отсюда
Психолог Брюс Такман предложил модель развития команды, которая хорошо ложится на наш ИТ мир. Менеджеры любят к ней апелировать и спрашивать на собеседованиях. Она несложная, убедитесь сами:
❗❗ Каждая команда с первого дня пройдет 4 стадии роста: forming, storming, norming, performing.
Давайте рассмотрим каждую из них.
👋 Forming
На первой стадии все учтивы и доброжелательны, присматриваются друг к другу. Конфликтов избегают. Людям хочется произвести хорошее впечатление, поэтому они работают чуть лучше и больше обычного. Для менеджера это главное время зарабатывать авторитет и устанавливать границы что можно, а что нельзя.
🖕 Storming
Игра престолов начинается здесь. Люди поняли, кто чего стоит и потихоньку начинают разыгрывать локальные войнушки.
Кто-то уйдет: "в гробу я видал такого тимлида!".
Кто-то отмалчивается: "сами как-нибудь разберутся, зп капает и ОК".
Кто-то проталкивает свои идеи: "я в прошлой компании писал на vue.js, проект взлетел, давайте и тут все перепишем".
На производительности это сказывается плохо, из-за споров и разногласий работа делается долго.
🤝 Norming
Рано или поздно, народ устает выяснять отношения и кто-то вспоминает, что пришел сюда решать задачи. Люди потихоньку начинают слушать друг друга, договариваться, искать компромисс. Появляются ростки доверия и эмпатия. Как следствие, растет скорость закрытия задач.
На этой стадии ПМ уже задумывается о делегировании.
💪 Performing
На ретроспективе все чаще слышно "у нас сильная команда, все друг другу помогают". Шишки набиты, ответственность распределена, все знают что и как работать. Уйти в отпуск на 3 недели не проблема. Функция менеджера тут поддерживающая. Без него не обойтись только во внештатных и критических ситуациях.
Вот и все, теперь вы знаете модель Такмана.
--------------------------------
Картинка отсюда
Зачем это надо
Зная эту схему, можно принимать управленческие решения с оглядкой на текущее состояние команды.
Например, на форминге ОК сказать: "так, я все обдумал и решил, гребем вот сюда". А в другой момент, на перформинге: "ребята, вы уже взрослые, я вам доверяю, решайте сами, куда грести". Так помогаешь команде быстрее придти к следующей стадии.
👉 По моим ощущениям, перейти от первой стадии на последнюю у новой команды занимает от 6 месяцев до года.
А по вашим?
Зная эту схему, можно принимать управленческие решения с оглядкой на текущее состояние команды.
Например, на форминге ОК сказать: "так, я все обдумал и решил, гребем вот сюда". А в другой момент, на перформинге: "ребята, вы уже взрослые, я вам доверяю, решайте сами, куда грести". Так помогаешь команде быстрее придти к следующей стадии.
👉 По моим ощущениям, перейти от первой стадии на последнюю у новой команды занимает от 6 месяцев до года.
А по вашим?
Как вырасти в ПМ (или в кого угодно)
Часто в директе спрашивают "Как перейти в ПМы?". Сегодня расскажу про самый простой и органичный, на мой взгляд, способ. Он состоит из 2х шагов.
Шаг 1. Спроси у своего менеджера, чем ему помочь.
У твоего менеджера точно много работы. Часть ее он будет рад делегировать. Попроси отдать тебе какую-нибудь простую задачу и научись делать ее хорошо.
Например, ты работаешь единственным тестером на проекте. Пишешь своему ПМу: "Саша, вот ты проводишь демо спринта каждые 2 недели. Мне хочется расти, можешь показать как ты его готовишь? Я бы мог продемить несколько фич в следующий раз, если тебе ОК. У тебя наверняка других дел по горло :)". Если Саша не мудак, то, скорее всего, ему ОК и он все покажет.
Потом Саша уйдет в отпуск и попросит провести ретру. Потом подключиться на звонок с клиентом. Так ты попробуешь одну задачу, вторую, третью и со временем получишь опыт по большинству обязанностей проджекта. Какие-то из них тебе даже отдадут на постоянной основе! Например, проектные отчеты любой ПМ с удовольствием делегирует навсегда 😎.
Проект растет, нанимают еще одного QA и, видя твою активность, назначают QA лидом. А там уже и до ПМ полшага.
Шаг 2. Внутренние собеседования.
Если целишься в работу проджекта, надо точно знать, чего ждут работодатели. Открой сайт с вакансиями ПМ и выпиши оттуда обязанности. Это список того, в чем надо разобраться и в идеале попробовать на шаге 1.
Научившись делать большую часть из них, пробуй пройти собеседование. Для начала проведи его в текущей компании, здесь к тебе более лояльны.
Найди ресурсного менеджера ПМов, расскажи ему, чем занимался и попроси прособеседовать тебя, как будто он нанимает обычного менеджера с рынка. Кстати, отзывы Саши тут могут пригодиться.
С первого раза работу вряд ли предложат. Но точно дадут фидбек, что надо докачать и может даже помогут с подготовкой. В этом преимущество проходить собес именно на текущем месте. Повторишь спустя 3 месяца, и через несколько таких итераций работа твоя.
Конечно же, на всех этапах подготовки помогут хорошие курсы, книги для новичков, семинары и так далее. Но это ты и сам знаешь.
------------------------------------------
Это универсальный подход. Пробуя новые задачи под присмотром человека, который уже умеет их делать, легко получить новые навыки. Как раньше из подмастерьев росли Микеланжело и Рафаэль, так и сейчас растут из разработчика в тимлида, из проджекта в продакты и в кого угодно вообще.
Часто в директе спрашивают "Как перейти в ПМы?". Сегодня расскажу про самый простой и органичный, на мой взгляд, способ. Он состоит из 2х шагов.
Шаг 1. Спроси у своего менеджера, чем ему помочь.
У твоего менеджера точно много работы. Часть ее он будет рад делегировать. Попроси отдать тебе какую-нибудь простую задачу и научись делать ее хорошо.
Например, ты работаешь единственным тестером на проекте. Пишешь своему ПМу: "Саша, вот ты проводишь демо спринта каждые 2 недели. Мне хочется расти, можешь показать как ты его готовишь? Я бы мог продемить несколько фич в следующий раз, если тебе ОК. У тебя наверняка других дел по горло :)". Если Саша не мудак, то, скорее всего, ему ОК и он все покажет.
Потом Саша уйдет в отпуск и попросит провести ретру. Потом подключиться на звонок с клиентом. Так ты попробуешь одну задачу, вторую, третью и со временем получишь опыт по большинству обязанностей проджекта. Какие-то из них тебе даже отдадут на постоянной основе! Например, проектные отчеты любой ПМ с удовольствием делегирует навсегда 😎.
Проект растет, нанимают еще одного QA и, видя твою активность, назначают QA лидом. А там уже и до ПМ полшага.
Шаг 2. Внутренние собеседования.
Если целишься в работу проджекта, надо точно знать, чего ждут работодатели. Открой сайт с вакансиями ПМ и выпиши оттуда обязанности. Это список того, в чем надо разобраться и в идеале попробовать на шаге 1.
Научившись делать большую часть из них, пробуй пройти собеседование. Для начала проведи его в текущей компании, здесь к тебе более лояльны.
Найди ресурсного менеджера ПМов, расскажи ему, чем занимался и попроси прособеседовать тебя, как будто он нанимает обычного менеджера с рынка. Кстати, отзывы Саши тут могут пригодиться.
С первого раза работу вряд ли предложат. Но точно дадут фидбек, что надо докачать и может даже помогут с подготовкой. В этом преимущество проходить собес именно на текущем месте. Повторишь спустя 3 месяца, и через несколько таких итераций работа твоя.
Конечно же, на всех этапах подготовки помогут хорошие курсы, книги для новичков, семинары и так далее. Но это ты и сам знаешь.
------------------------------------------
Это универсальный подход. Пробуя новые задачи под присмотром человека, который уже умеет их делать, легко получить новые навыки. Как раньше из подмастерьев росли Микеланжело и Рафаэль, так и сейчас растут из разработчика в тимлида, из проджекта в продакты и в кого угодно вообще.
Кейс про плохие новости
Представьте, что с вашего проекта решили уйти сразу 2 человека - разработчик Паша и тестировщица Оксана. Сотрудники ценные, не хотелось их терять, поэтому целую неделю вы обсуждали варианты, как им остаться. К сожалению, договориться не получилось и ребята уже гарантировано уходят.
Переговоры с Пашей закончились во вторник, с Оксаной - в четверг.
Представьте, что с вашего проекта решили уйти сразу 2 человека - разработчик Паша и тестировщица Оксана. Сотрудники ценные, не хотелось их терять, поэтому целую неделю вы обсуждали варианты, как им остаться. К сожалению, договориться не получилось и ребята уже гарантировано уходят.
Переговоры с Пашей закончились во вторник, с Оксаной - в четверг.
Комментарии к кейсу про плохие новости ^
☑️ A - На следующий день после завершения переговоров - в среду и пятницу. В этом варианте есть два небольших плюса.
Первый - в том, что команда узнает новость раньше всех. Это помогает строить честные отношения с менеджером - ребята видят, что от них ничего не скрывают и вся проектная инфа сразу доходит до них, минуя "министерство правды".
Второй - у вас будет на 2 дня больше для передачи дел и открытия вакансии.
Все же, вариант B более выгодный.
✅ B - В один день расскажу про уход обоих - в пятницу. Я выбираю этот вариант, потому что уход двух человек - это одна плохая новость. Уход Оксаны, а через несколько дней, уход Паши - это уже две плохие новости, хоть и менее масштабные. В голове команды это разница между "в январе от нас ушли Оксана и Паша" и "сначала Оксана от нас ушла, а за ней еще Паша....". Первое воспринимается менее депрессивно.
Да, будет на 2 дня меньше на передачу дел и поиск нового человека. Но уходят обычно за месяц, поэтому 2 дня погоды не сделают (если это не ваш случай - берите вариант А).
❌ C - В последний день их работы - этот вариант плох тем, что не дает команде времени "попрощаться" с сотрудником. Могут подумать, что вы что-то скрываете и не хотите, чтобы Оксана и Паша сболтнули лишнего. Или что их уволили одним днем. И то и другое бросает негативную тень на проект, а, следовательно, и на менеджера.
Любопытно, что этот вариант выбрало около 10% менеджеров. Поделитесь в комментариях в чем здесь может быть выгода?
------------------------
P.S.
1️⃣ В комментариях звучало много мнений о том, что команда все узнает еще раньше официальных новостей. Необязательно. Чтобы этого не случилось попросите сотрудника не распространяться коллегам об уходе. Если у вас нормальные отношения - согласится.
2️⃣ Очень классный вариант предложил Антон Корнев:
1. узнаю, с кем сотрудники уже обсуждали свой уход. может быть все уже в курсе, и нет смысла долго держать в тайне
2. если никто не в курсе, то сначала с теми, кто уходит, проговорю стратегию. как я понимаю, они не из-за проблем в проекте уходят, поэтому важно не создать у команды впечатления, что всё может быть плохо. Тут же назначим день, когда сообщить команде
3. действуем по договоренности ) плюс попрошу ребят озвучить причины ухода остальным, если это возможно
☑️ A - На следующий день после завершения переговоров - в среду и пятницу. В этом варианте есть два небольших плюса.
Первый - в том, что команда узнает новость раньше всех. Это помогает строить честные отношения с менеджером - ребята видят, что от них ничего не скрывают и вся проектная инфа сразу доходит до них, минуя "министерство правды".
Второй - у вас будет на 2 дня больше для передачи дел и открытия вакансии.
Все же, вариант B более выгодный.
✅ B - В один день расскажу про уход обоих - в пятницу. Я выбираю этот вариант, потому что уход двух человек - это одна плохая новость. Уход Оксаны, а через несколько дней, уход Паши - это уже две плохие новости, хоть и менее масштабные. В голове команды это разница между "в январе от нас ушли Оксана и Паша" и "сначала Оксана от нас ушла, а за ней еще Паша....". Первое воспринимается менее депрессивно.
Да, будет на 2 дня меньше на передачу дел и поиск нового человека. Но уходят обычно за месяц, поэтому 2 дня погоды не сделают (если это не ваш случай - берите вариант А).
❌ C - В последний день их работы - этот вариант плох тем, что не дает команде времени "попрощаться" с сотрудником. Могут подумать, что вы что-то скрываете и не хотите, чтобы Оксана и Паша сболтнули лишнего. Или что их уволили одним днем. И то и другое бросает негативную тень на проект, а, следовательно, и на менеджера.
Любопытно, что этот вариант выбрало около 10% менеджеров. Поделитесь в комментариях в чем здесь может быть выгода?
------------------------
P.S.
1️⃣ В комментариях звучало много мнений о том, что команда все узнает еще раньше официальных новостей. Необязательно. Чтобы этого не случилось попросите сотрудника не распространяться коллегам об уходе. Если у вас нормальные отношения - согласится.
2️⃣ Очень классный вариант предложил Антон Корнев:
1. узнаю, с кем сотрудники уже обсуждали свой уход. может быть все уже в курсе, и нет смысла долго держать в тайне
2. если никто не в курсе, то сначала с теми, кто уходит, проговорю стратегию. как я понимаю, они не из-за проблем в проекте уходят, поэтому важно не создать у команды впечатления, что всё может быть плохо. Тут же назначим день, когда сообщить команде
3. действуем по договоренности ) плюс попрошу ребят озвучить причины ухода остальным, если это возможно
Кейс про небольшую доработку
Это реальная история, которая случилась со мной недавно.
Один клиент попросил сделать фичу - запуск нашего SDK в табке. Хотел реализовать такой флоу, как в инстаграме (см. картинки внизу).
Описание понятное, звучит как небольшая доработка. Просто взять да запустить наше великолепное, блестяще работающее SDK в новом представлении, как в новой вкладке.
Иду разговаривать к разработчику, рассказываю про фичу. Тоже нет проблем, добавим там метод present, который... дальше что-то на разработческом.
Таска легкая займет 2 дня с рисками, тестами и багфиксами. Супер. Заказчика все устраивает, начинаем разработку.
Сделали даже быстрее и через 1,5 дня пулл реквест был на столе у тестировщиков.
Это реальная история, которая случилась со мной недавно.
Один клиент попросил сделать фичу - запуск нашего SDK в табке. Хотел реализовать такой флоу, как в инстаграме (см. картинки внизу).
Описание понятное, звучит как небольшая доработка. Просто взять да запустить наше великолепное, блестяще работающее SDK в новом представлении, как в новой вкладке.
Иду разговаривать к разработчику, рассказываю про фичу. Тоже нет проблем, добавим там метод present, который... дальше что-то на разработческом.
Таска легкая займет 2 дня с рисками, тестами и багфиксами. Супер. Заказчика все устраивает, начинаем разработку.
Сделали даже быстрее и через 1,5 дня пулл реквест был на столе у тестировщиков.
Комментарий к кейсу про доработку ^
Когда фича дошла до QA, в ней нашли миллион эдж кейсов:
- делаешь фото, в этот момент включаешь другую вкладку, апа крашится
- делаешь съемку с таймером, пока идет обратный отсчет, переходишь в другую вкладку, съемка продолжается (хотя юзер уже в другой вкладке ).
и т.п.
Все потому, что когда мы делали оценку, то думали о работе SDK только в контексте самого SDK. А механизм вкладок вносит доп логику снаружи. Благодаря ему юзер может одновременно использовать другие фичи приложения в других вкладках. Там может оказаться еще одна камера, еще одна вспышка, любой функционал, дублирующий наш, или, что еще хуже, противоречащих нашему. Это определенно вызвало бы "помехи", которые мы и начали ловить в эдж кейсах.
Заказчик, конечно, не рассчитывал на них, ему нужна стабильная работа с любой его фичей. Сдать работу в таком состоянии мы, разумеется, не могли. Сложность была в том, что клиентов у SDK много, а поставка для всех одна. То есть, если фича выпускается, то ее получают все клиенты, нельзя отдать только одному.
Получается, что фича нарушает принцип универсальности поставки. Т.е. под каждого клиента ее пришлось бы адаптировать и что-то чинить. Представьте, чего стоила бы поддержка на сотне кастомеров! Поэтому задачу мы откатили, до продакшена она не дошла.
Для заказчика, конечно, это не было хорошей новостью. Мы ему что-то наобещали, а потом этого не дали - худший сон ПМа. Но даже если бы он от нас ушел, это все равно вышло бы дешевле, чем поддерживать эту фичу. В моменте мы потеряли, но сэкономили на долгой дистанции.
Когда фича дошла до QA, в ней нашли миллион эдж кейсов:
- делаешь фото, в этот момент включаешь другую вкладку, апа крашится
- делаешь съемку с таймером, пока идет обратный отсчет, переходишь в другую вкладку, съемка продолжается (хотя юзер уже в другой вкладке ).
и т.п.
Все потому, что когда мы делали оценку, то думали о работе SDK только в контексте самого SDK. А механизм вкладок вносит доп логику снаружи. Благодаря ему юзер может одновременно использовать другие фичи приложения в других вкладках. Там может оказаться еще одна камера, еще одна вспышка, любой функционал, дублирующий наш, или, что еще хуже, противоречащих нашему. Это определенно вызвало бы "помехи", которые мы и начали ловить в эдж кейсах.
Заказчик, конечно, не рассчитывал на них, ему нужна стабильная работа с любой его фичей. Сдать работу в таком состоянии мы, разумеется, не могли. Сложность была в том, что клиентов у SDK много, а поставка для всех одна. То есть, если фича выпускается, то ее получают все клиенты, нельзя отдать только одному.
Получается, что фича нарушает принцип универсальности поставки. Т.е. под каждого клиента ее пришлось бы адаптировать и что-то чинить. Представьте, чего стоила бы поддержка на сотне кастомеров! Поэтому задачу мы откатили, до продакшена она не дошла.
Для заказчика, конечно, это не было хорошей новостью. Мы ему что-то наобещали, а потом этого не дали - худший сон ПМа. Но даже если бы он от нас ушел, это все равно вышло бы дешевле, чем поддерживать эту фичу. В моменте мы потеряли, но сэкономили на долгой дистанции.
1 картинка вместо 1000 слов
Заметил, что читая что-то в интернете первым делом смотрю на картинку, если она есть. Некоторые ресурсы заморачиваются с визуальным повествованием и добавляют комментарии прямо на сами на картинки, рисуют схемы. Читать такой текст в разы проще и быстрее, сразу становится понятно о чем идет речь. Посмотрел картинку, глянул на заголовок, если это мэтч, то дальше уже можно и не читать. По диагонали максимум пробежаться.
Хорошо подобрать картинку - это целое искусство. В некоторых медиа для этого даже есть специальные люди - пикчеры.
У нас в команде нету пикчеров, но мы тоже любим картинки. Используем их для описания багов, прикрепляем скриншоты проблем. Тогда разработчикам сразу ясно, что чинить. Так мы экономим немного времени читателям нашей джиры.
Как говорится, лучше один раз увидеть, что сто раз прочитать в тикете.
Заметил, что читая что-то в интернете первым делом смотрю на картинку, если она есть. Некоторые ресурсы заморачиваются с визуальным повествованием и добавляют комментарии прямо на сами на картинки, рисуют схемы. Читать такой текст в разы проще и быстрее, сразу становится понятно о чем идет речь. Посмотрел картинку, глянул на заголовок, если это мэтч, то дальше уже можно и не читать. По диагонали максимум пробежаться.
Хорошо подобрать картинку - это целое искусство. В некоторых медиа для этого даже есть специальные люди - пикчеры.
У нас в команде нету пикчеров, но мы тоже любим картинки. Используем их для описания багов, прикрепляем скриншоты проблем. Тогда разработчикам сразу ясно, что чинить. Так мы экономим немного времени читателям нашей джиры.
Как говорится, лучше один раз увидеть, что сто раз прочитать в тикете.