Forwarded from Product Developer
Процессы как отмазка
Disclaimer: в этом посте общественной пользы нет.
Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану.
Я считаю, что любое повторяющееся действие должно быть структурировано, описано и закреплено процессом. Особенно, если это действие делают разные люди, чередуясь. Без описания это неформальная договоренность, возможность нафакапить и повод для будущего конфликта.
НО. Меня люто бесят люди, которые облажались и не признают свой косяк, не делают выводов для себя и оправдываются отсутствием / недостаточной структурированностью процесса.
Вы поймите правильно, я и процессы люблю и людей. И лажаю сам частенько. Очень радуюсь, когда кто-то как следует прикладывает прод, так чтобы разгребать было интересно, и в будущем мы никогда больше не приложили бы прод подобным образом.
НО. Очень уж дофига человеколюбия в последнее время в этом нашем айти. Когда кто-то облажался, мы ищем ему оправдание в хреновости процесса и ищем системное решение в виде доработки процесса. На ретроспективах стараемся не шеймить человека, а предлагать решения в виде регламента, чеклиста, бота с напоминаниями, второй пары глаз, еще чего-то. Это поможет, если человек понимает, что облажался.
Но бывает, что один и тот же человек находит изъяны всех ваших процессов. Находит способ облажаться в любом действии. В котором не лажают другие. Процессы всегда не идеальны. Структурированность процессов — баланс между бюрократическим оверхедом и стремлением снизить человеческий фактор. И ради одного персонажа вы из раза в раз добавляете оверхед в процессы. А он из раза в раз находит изъяны этого процесса.
Что будете делать с таким человеком? Ведь он старается, работает, пользу приносит. Или вред?
Disclaimer: в этом посте общественной пользы нет.
Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану.
Я считаю, что любое повторяющееся действие должно быть структурировано, описано и закреплено процессом. Особенно, если это действие делают разные люди, чередуясь. Без описания это неформальная договоренность, возможность нафакапить и повод для будущего конфликта.
НО. Меня люто бесят люди, которые облажались и не признают свой косяк, не делают выводов для себя и оправдываются отсутствием / недостаточной структурированностью процесса.
Вы поймите правильно, я и процессы люблю и людей. И лажаю сам частенько. Очень радуюсь, когда кто-то как следует прикладывает прод, так чтобы разгребать было интересно, и в будущем мы никогда больше не приложили бы прод подобным образом.
НО. Очень уж дофига человеколюбия в последнее время в этом нашем айти. Когда кто-то облажался, мы ищем ему оправдание в хреновости процесса и ищем системное решение в виде доработки процесса. На ретроспективах стараемся не шеймить человека, а предлагать решения в виде регламента, чеклиста, бота с напоминаниями, второй пары глаз, еще чего-то. Это поможет, если человек понимает, что облажался.
Но бывает, что один и тот же человек находит изъяны всех ваших процессов. Находит способ облажаться в любом действии. В котором не лажают другие. Процессы всегда не идеальны. Структурированность процессов — баланс между бюрократическим оверхедом и стремлением снизить человеческий фактор. И ради одного персонажа вы из раза в раз добавляете оверхед в процессы. А он из раза в раз находит изъяны этого процесса.
Что будете делать с таким человеком? Ведь он старается, работает, пользу приносит. Или вред?
👍7🔥3💊3
Product Developer
Процессы как отмазка Disclaimer: в этом посте общественной пользы нет. Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану. Я считаю, что любое повторяющееся действие должно быть структурировано…
Пост моего тимлида напомнил мне историю из сберздоровья
Когда я пришел из аутсорса в продуктовую разработку, то выбрал продукт, помогающий людям стать здоровыми. Я, как всегда, не выбирал по размеру оффера. А по уровню социальной значимости. Да и хотел отмыть грязь после аутсорса.
Спустя пару месяцев я узнал, что пользователи почти не оставляют позитивных оценок. 1 положительный отзыв на 20 негативных. Тогда мне стало грустно, ведь я хотел получить фидбэк от юзеров.
С тех пор стало понятно, что рынок СНГ не умеет давать положительного фидбэка. Люди считают негативный коммент полезней позитивного. Вроде круто, но это выстреливает всяким оптимизаторам сторов и пиар компаниям. Да и затрудняет путь обычным работягам, которые хотят сделать крутой продукт.
Когда я пришел из аутсорса в продуктовую разработку, то выбрал продукт, помогающий людям стать здоровыми. Я, как всегда, не выбирал по размеру оффера. А по уровню социальной значимости. Да и хотел отмыть грязь после аутсорса.
Спустя пару месяцев я узнал, что пользователи почти не оставляют позитивных оценок. 1 положительный отзыв на 20 негативных. Тогда мне стало грустно, ведь я хотел получить фидбэк от юзеров.
С тех пор стало понятно, что рынок СНГ не умеет давать положительного фидбэка. Люди считают негативный коммент полезней позитивного. Вроде круто, но это выстреливает всяким оптимизаторам сторов и пиар компаниям. Да и затрудняет путь обычным работягам, которые хотят сделать крутой продукт.
💯11💊6❤🔥2🫡2👍1
Тут скинули инфу, что это не только проблема ИТ, и не только СНГ. Проблеме плохого фидбэка уже лет 100 и, как всегда, все начинается с психологии
https://www.nytimes.com/2018/06/13/smarter-living/trust-negative-product-reviews.html
https://www.nytimes.com/2018/06/13/smarter-living/trust-negative-product-reviews.html
NY Times
Why You Can’t Really Trust Negative Online Reviews (Published 2018)
Research suggests that people heed negative reviews more than positive ones — despite their questionable credibility.
👍6💊2
Приложение написанное с помощью нейросети
Твиттер-тред о том, как автор без написания кода и дизайнеров сам сделал приложение.
Джунам все сложнее и сложнее...
Твиттер-тред о том, как автор без написания кода и дизайнеров сам сделал приложение.
Джунам все сложнее и сложнее...
💊20🌚2💔2
Последний пост про телеграм конкурс, общаю.
Мое главное селф-ревью. Всем, кто хотел каких-то комментариев — читайте картинки. Получилось лаконично (половина редакторы порезали), но по-другому никак
Спасибо вам и этому каналу.
Мое главное селф-ревью. Всем, кто хотел каких-то комментариев — читайте картинки. Получилось лаконично (половина редакторы порезали), но по-другому никак
Спасибо вам и этому каналу.
Forwarded from AvitoTech
Лев Бондаренко, наш iOS-разработчик из кластера Trust&Safety, по совместительству автор канала iOS makes me cry, недавно участвовал в Telegram Call UI Contest. Не просто участвовал, а занял там призовое место.
Мы встретились со Львом и задали ему вопросы. Получилось небольшое интервью, которым делимся с вами💜
#avitoteam
Мы встретились со Львом и задали ему вопросы. Получилось небольшое интервью, которым делимся с вами
#avitoteam
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥33❤🔥6👍4💊2⚡1
О доверии
Мы уже выяснили, что скажи человеку ничего не делать и получать за это лям, то он будет ныть почему не 2ляма получает и обвинять в этом процессы, систему.
Но что делать, если тебе говорят, что все вокруг врут и надо тоже врать? Эту проблему уже давно разобрали математики в теории игр. Самая лучшая стратегия доверия или вранья смоделирована уже давно.
Пройдите игру и решите сами какой путь выгоден вам. Спойлервсем врать плохо математически
https://notdotteam.github.io/trust/
Мы уже выяснили, что скажи человеку ничего не делать и получать за это лям, то он будет ныть почему не 2ляма получает и обвинять в этом процессы, систему.
Но что делать, если тебе говорят, что все вокруг врут и надо тоже врать? Эту проблему уже давно разобрали математики в теории игр. Самая лучшая стратегия доверия или вранья смоделирована уже давно.
Пройдите игру и решите сами какой путь выгоден вам. Спойлер
https://notdotteam.github.io/trust/
notdotteam.github.io
Эволюция доверия
интерактивное руководство теории игр о том, зачем и как мы доверяем друг другу
👍12💊5🆒2
Не знаю зачем пишу это, но дико нравится программировать под музыку Deus Ex. Как я уже говорил: музыка — это одно из первых в процессе
https://www.youtube.com/watch?v=7lERcfsqJSk
https://www.youtube.com/watch?v=7lERcfsqJSk
YouTube
Deus Ex: Ambient Mix (Mankind Divided // Human Revolution)
Audio used belongs to the composers: Michael McCann / Ed Harrison / Sascha Dikiciyan
DxMD 1 :
00:00 Otar Botkoveli Debate
04:06 Prague - First visit ambience
07:33 Prague - General ambience
11:32 Adam's Apartment
14:20 Allison Stanek Debate
DxMD 2 :
18:01…
DxMD 1 :
00:00 Otar Botkoveli Debate
04:06 Prague - First visit ambience
07:33 Prague - General ambience
11:32 Adam's Apartment
14:20 Allison Stanek Debate
DxMD 2 :
18:01…
🔥11👍3
"Краудсорсинг: Коллективный разум как инструмент развития бизнеса" | Хау Джефф
Если бы был мой список книг, которые на меня повлияли, то эта была бы в топ 3. Опять же о ней узнал из библиотеки сбера от Грефа.
Прошло много лет и я почти не помню о чем она. Надо перечитать. Но сама идея коллективного труда коммьюнити и личностей в нем перекочевала в этот канал.
Это — ядро моей мотивации. Ни деньги рекламодателей. Ни лайки. Ни интервью, мок-собесы, твиттер-посты, исследования и доклады.
Главный стимул — получение удовлетворения через создания мощного интеллектуального ресурса. Или, как минимум, игрушки с ним
#books
Если бы был мой список книг, которые на меня повлияли, то эта была бы в топ 3. Опять же о ней узнал из библиотеки сбера от Грефа.
Прошло много лет и я почти не помню о чем она. Надо перечитать. Но сама идея коллективного труда коммьюнити и личностей в нем перекочевала в этот канал.
Это — ядро моей мотивации. Ни деньги рекламодателей. Ни лайки. Ни интервью, мок-собесы, твиттер-посты, исследования и доклады.
Главный стимул — получение удовлетворения через создания мощного интеллектуального ресурса. Или, как минимум, игрушки с ним
#books
👍5🔥3⚡1
This media is not supported in your browser
VIEW IN TELEGRAM
Одна из частых задач разработчика — обновить состояния предыдущих экранов, модулей, компонентов. Её также любят давать на собесах.
Практический кейс такой: у нас есть список товаров. Товары могут быть в избранном, просмотренные или в корзине. При переходе на детальный экран и добавление в избранное или корзину нужно обновлять состояния в списке товаров и других местах.
Супер стандартная ситуация. Прежде чем напишу решения, попрошу работу в группах. Какие практиками или паттернами решили эту проблему? Подумайте и напишите в комментариях какие подходы делали в своих проектах. По желанию с плюсами и минусами.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤡10👍6🦄3
Наконец вы можете прокачать навыки иосника и не быть заложниками блоггеров, кто пересказывает документации.
Новый уровень в образовании:
- Тренажеры на любой кейс
- Онлайн чат с тысячами разработчиками
- Искусственный интеллект, адаптирующийся под любые сценарии собесов
- Миллиард гигабайт ресурсов
- Онлайн генератор резюме
- Хаки по собесам
- Лучший ученик получает оффер в эйпл
- Автограф разработчика (мой)
- Чат поддержки с hr'ами всего мира, чтобы помогли пожаловаться о сломанной системе найма. Вам перезвонят
- Генератор дипломов высшего образования высшего качества
Скачать симулятор по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
🤡65👍5💊3⚡2
iOS Makes Me Hate
Ответ на этот пост такой:
Конечно, все зависит от задачи и никогда не нужно переусложнять (вспоминаем KISS, YAGNI). Давайте разберем хорошие варианты:
1. Сервис Observable. На мой взгляд для решения этой задачи достаточно обыкновенного слушателя. Не нужно тащить RX фреймворки (чаще это излишне). Хороший сервис помогает легко переиспользовать код через DI и облегчает тестирование, уменьшает дублирование кода
2. Паттерн Repository. Хранить все idшники избранных, товаров в корзине и других необходимых сущностей в отдельных хранилищах. Также обновлять эти хранилища и отсылать сигналы потребителям. Тут есть соблазн уйти в хранение данных локально. На мой взгляд эта необходимость нужна только тогда, когда в приложении сильно запроектированна логика офлайна
3.🥇 Синглтон. Ну и главный победитель, который не нуждается в комментариях
Вы легко это можете оспорить.
Конечно, все зависит от задачи и никогда не нужно переусложнять (вспоминаем KISS, YAGNI). Давайте разберем хорошие варианты:
1. Сервис Observable. На мой взгляд для решения этой задачи достаточно обыкновенного слушателя. Не нужно тащить RX фреймворки (чаще это излишне). Хороший сервис помогает легко переиспользовать код через DI и облегчает тестирование, уменьшает дублирование кода
2. Паттерн Repository. Хранить все idшники избранных, товаров в корзине и других необходимых сущностей в отдельных хранилищах. Также обновлять эти хранилища и отсылать сигналы потребителям. Тут есть соблазн уйти в хранение данных локально. На мой взгляд эта необходимость нужна только тогда, когда в приложении сильно запроектированна логика офлайна
3.
Вы легко это можете оспорить.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🖕4🫡3⚡1🍾1💊1
О грейдах
Это последний пост. Я беру паузу, пока не зарелизю симулятор.
Никогда не будет общих стандартов. Никогда не будет одних критерий для мидлов, сеньоров, лидов. Все зависит от множества факторов.
От среды обитания, от культуры, от бизнес моделей, от culture fit, от распределенных ресурсов, от форм управления.
Еще больше я это понимаю, когда общаюсь с вами, получаю опыт, работаю в разных компаниях вашими глазами или хожу по собесам.
Банальное отличие. Годами качать необходимые навыки и думая, что добравшись до вершины карьерной лестницы тебе откроются все двери.
Вспомним слова Павла Дурова. Иногда, а может и часто, бывает так, что чем выше ты поднимаешься в одном месте, тем ниже тебя ценят в другом. И наоборот.
Например, даже взять сравнение с авито и яндексом. В авито ценят умение решать практические алгоритмы и уходить от синтетических, абстрактных. На них жесткий фильтр. А Яндекс славится обратным и они видят в абстрактных задачах скилл разработчиков.
Или в одних компаниях ценят, чтобы разработчик брал на себя как можно больше только своих задач. А в других брать чужие задачи это важно и нужно развивать t-shape.
Все грейды — это формулировки требований одного бизнеса, а не целого рынка. Бизнес думает, как выгодно ему. Что же такое карьерный успех? Тут уже каждый сам отвечает. Высокая должность в найме, доход в месяц, выигранные награды в конкурсах, запуск успешного бизнеса.
Поэтому не стоит смотреть на симулятор, как на ключ ко всем дверям. Не стоит смотреть на этот блог. Не стоит так на все курсы, образование, матрицы компетенций. На свою должность и что либо еще. Все это лишь инструменты, а как и для чего мы этим пользуемся — наша ответственность.
Нет универсального сценария. Есть только ветки, которые выбираем мы под свои требования и вкусы.
Это последний пост. Я беру паузу, пока не зарелизю симулятор.
Никогда не будет общих стандартов. Никогда не будет одних критерий для мидлов, сеньоров, лидов. Все зависит от множества факторов.
От среды обитания, от культуры, от бизнес моделей, от culture fit, от распределенных ресурсов, от форм управления.
Еще больше я это понимаю, когда общаюсь с вами, получаю опыт, работаю в разных компаниях вашими глазами или хожу по собесам.
Банальное отличие. Годами качать необходимые навыки и думая, что добравшись до вершины карьерной лестницы тебе откроются все двери.
Вспомним слова Павла Дурова. Иногда, а может и часто, бывает так, что чем выше ты поднимаешься в одном месте, тем ниже тебя ценят в другом. И наоборот.
Например, даже взять сравнение с авито и яндексом. В авито ценят умение решать практические алгоритмы и уходить от синтетических, абстрактных. На них жесткий фильтр. А Яндекс славится обратным и они видят в абстрактных задачах скилл разработчиков.
Или в одних компаниях ценят, чтобы разработчик брал на себя как можно больше только своих задач. А в других брать чужие задачи это важно и нужно развивать t-shape.
Все грейды — это формулировки требований одного бизнеса, а не целого рынка. Бизнес думает, как выгодно ему. Что же такое карьерный успех? Тут уже каждый сам отвечает. Высокая должность в найме, доход в месяц, выигранные награды в конкурсах, запуск успешного бизнеса.
Поэтому не стоит смотреть на симулятор, как на ключ ко всем дверям. Не стоит смотреть на этот блог. Не стоит так на все курсы, образование, матрицы компетенций. На свою должность и что либо еще. Все это лишь инструменты, а как и для чего мы этим пользуемся — наша ответственность.
Нет универсального сценария. Есть только ветки, которые выбираем мы под свои требования и вкусы.
👍21💊5❤🔥2🤬1🫡1🆒1🦄1
А что для вас карьерный успех?
Anonymous Poll
19%
Высокая должность
73%
Высокий доход
37%
Независимость
8%
Медийность
49%
Успешные продукты
31%
Разработанные технологии
2%
Другое (в комменты)
3%
Не знаю
💊3👍1