😁35😭6💩3🤔1
242. О сложных процессах
Коллега рассказывал как работал в жутко секретном отделении немецкого автопроизводителя:
— У нас компьютеры блокировались с помощью usb-токена. Вставляешь такую флешку в комп и он работает. Вынимаешь – блокируется. Уйти из комнаты, не заблокировав компьютер, не выйдет, потому что этот же токен открывает дверь. Хочешь сходить в туалет – вынимаешь из компьютера флешку, с ее помощью открываешь дверь помещения. Выйти вместе с коллегой из комнаты не выйдет – за этим следят камеры.
В общем, хорошие меры безопасности. Можно понять хозяев: все же конкуренция между автопроизводителями высокая, украсть секреты у лидеров рынка мечтают многие. Поэтому сотрудникам приходится терпеть неудобства ради безопасности.
Конечно нет! Любой сложный дорогостоящий процесс скорее всего саботируется на местах. Поэтому выслушав рассказ коллеги, я спросил, неужели действительно все так секретно было? Он честно ответил:
— Да ну, брось ты. Все эти стандарты безопасности сделаны для успокоения головного офиса. С ними работать невозможно. Поэтому все файлы по работе мы пересылали друг другу через личные сообщения Вконтакте.
Две важные вещи о процессах: они должны быть простыми и уметь адаптироваться. В противном случае их быстро хакнут и начнут тайно саботировать.
Коллега рассказывал как работал в жутко секретном отделении немецкого автопроизводителя:
— У нас компьютеры блокировались с помощью usb-токена. Вставляешь такую флешку в комп и он работает. Вынимаешь – блокируется. Уйти из комнаты, не заблокировав компьютер, не выйдет, потому что этот же токен открывает дверь. Хочешь сходить в туалет – вынимаешь из компьютера флешку, с ее помощью открываешь дверь помещения. Выйти вместе с коллегой из комнаты не выйдет – за этим следят камеры.
В общем, хорошие меры безопасности. Можно понять хозяев: все же конкуренция между автопроизводителями высокая, украсть секреты у лидеров рынка мечтают многие. Поэтому сотрудникам приходится терпеть неудобства ради безопасности.
Конечно нет! Любой сложный дорогостоящий процесс скорее всего саботируется на местах. Поэтому выслушав рассказ коллеги, я спросил, неужели действительно все так секретно было? Он честно ответил:
— Да ну, брось ты. Все эти стандарты безопасности сделаны для успокоения головного офиса. С ними работать невозможно. Поэтому все файлы по работе мы пересылали друг другу через личные сообщения Вконтакте.
Две важные вещи о процессах: они должны быть простыми и уметь адаптироваться. В противном случае их быстро хакнут и начнут тайно саботировать.
🔥51👍17😁13
🤔13💩6👎2👌2
🔥11😁4💩3😱2😢2
243. Фигма – лучшая документация
Особенность айтишных продуктов – со временем никто не помнит, как всё работает. Я говорю не про коробочный продукт и не про сделанное на заказ для крупного клиента – там обычно есть документация. Я про типичный SAAS продукт. Он развивается итеративно, проводится множество экспериментов, делаются пивоты, меняются руководители и целые команды.
Через несколько лет никто не знает, как работает продукт. Кое что покрыто регрессионными тестами, но они проверяют лишь базовую логику. Как это работает «в принципе» знал только продакт, который уволился три года назад.
Бывает продакт описывает логику в техническом задании, но это случается редко. Обычно задачи ставятся в виде бедно оформленных карточек и обсуждаются устно и в чатах. Что делать менеджеру, кто придет через пару лет и будет пытаться разобраться «как это работает»? Я нашел выход – это Фигма.
Я прошу UX-дизайнера прорабатывать вместе со мной все состояния системы и фиксировать их в фигма макетах. Мы записываем комментарии по логике работы рядом с макетами на ярких плашках. Фигмовские нативные комментарии используем только для обсуждений, логику в них не пишем. Логика должна быть в виде простого текста рядышком с макетом.
Правильно сделанные макеты в Фигме – хорошее описание системы. Оно наглядно и понятно всем участникам – бэку, фронту, QA, менеджерам.
Конечно, макеты быстро устаревают. Но их в любом случае нужно делать, так что это как бы «бесплатная» документация. Нужно лишь проработать все состояния и дополнить их текстовыми комментариями.
Особенность айтишных продуктов – со временем никто не помнит, как всё работает. Я говорю не про коробочный продукт и не про сделанное на заказ для крупного клиента – там обычно есть документация. Я про типичный SAAS продукт. Он развивается итеративно, проводится множество экспериментов, делаются пивоты, меняются руководители и целые команды.
Через несколько лет никто не знает, как работает продукт. Кое что покрыто регрессионными тестами, но они проверяют лишь базовую логику. Как это работает «в принципе» знал только продакт, который уволился три года назад.
Бывает продакт описывает логику в техническом задании, но это случается редко. Обычно задачи ставятся в виде бедно оформленных карточек и обсуждаются устно и в чатах. Что делать менеджеру, кто придет через пару лет и будет пытаться разобраться «как это работает»? Я нашел выход – это Фигма.
Я прошу UX-дизайнера прорабатывать вместе со мной все состояния системы и фиксировать их в фигма макетах. Мы записываем комментарии по логике работы рядом с макетами на ярких плашках. Фигмовские нативные комментарии используем только для обсуждений, логику в них не пишем. Логика должна быть в виде простого текста рядышком с макетом.
Правильно сделанные макеты в Фигме – хорошее описание системы. Оно наглядно и понятно всем участникам – бэку, фронту, QA, менеджерам.
Конечно, макеты быстро устаревают. Но их в любом случае нужно делать, так что это как бы «бесплатная» документация. Нужно лишь проработать все состояния и дополнить их текстовыми комментариями.
❤29🔥14👍12
244. Читайте noreply
Многие сервисы отправляют письма с адреса noreply@. Адрес своим именем говорит: «Я робот, не надо отвечать на это письмо, не пойму». Обычно с этого адреса отправляют пароли и различные уведомления.
Многие продуктовые команды не читают письма, пришедшие на noreply, мол, туда только дурачки пишут. Некоторые даже настраивают автоответ: «Ваше письмо никто не прочел, сдохни, гадина». Но большинство просто не задумываются о такой проблеме. Спросите у вашего знакомого продакта, знает ли он, что пишут пользователи на noreply, и куда уходят эти письма.
Когда я прихожу в уже работающий продукт, я подписываюсь на эти письма и с удовольствием их читаю. Пользователи не смотрят на обратный адрес, а просто отвечают на письма и делятся своей болью. Кто-то жалуется, что у него платеж не прошел, кого-то постоянно разлогинивает и поэтому он вынужден восстанавливать забытый пароль, кто-то просит о новой фиче.
У нас noreply заведен в helpdesk систему и превращается в тикеты. Надо только отфильтровывать автоответы типа «Коллеги, я в отпуске».
Читайте все, что пишут пользователи. Даже если это отправлено на адрес непишимнебольше.
Многие сервисы отправляют письма с адреса noreply@. Адрес своим именем говорит: «Я робот, не надо отвечать на это письмо, не пойму». Обычно с этого адреса отправляют пароли и различные уведомления.
Многие продуктовые команды не читают письма, пришедшие на noreply, мол, туда только дурачки пишут. Некоторые даже настраивают автоответ: «Ваше письмо никто не прочел, сдохни, гадина». Но большинство просто не задумываются о такой проблеме. Спросите у вашего знакомого продакта, знает ли он, что пишут пользователи на noreply, и куда уходят эти письма.
Когда я прихожу в уже работающий продукт, я подписываюсь на эти письма и с удовольствием их читаю. Пользователи не смотрят на обратный адрес, а просто отвечают на письма и делятся своей болью. Кто-то жалуется, что у него платеж не прошел, кого-то постоянно разлогинивает и поэтому он вынужден восстанавливать забытый пароль, кто-то просит о новой фиче.
У нас noreply заведен в helpdesk систему и превращается в тикеты. Надо только отфильтровывать автоответы типа «Коллеги, я в отпуске».
Читайте все, что пишут пользователи. Даже если это отправлено на адрес непишимнебольше.
👍77🔥19🤔5
Из загадочного
1. Некоторые люди ставят в скобках лишние пробелы ( например так ).
2. Некоторые ставят пробел перед запятыми , например , так. Еще видел такой вариант ,например ,так ( ваще жесть ) !
Вот реально, не опечатываются, а каждый раз именно так и пишут. И даже утверждают, что это правильно.
1. Некоторые люди ставят в скобках лишние пробелы ( например так ).
2. Некоторые ставят пробел перед запятыми , например , так. Еще видел такой вариант ,например ,так ( ваще жесть ) !
Вот реально, не опечатываются, а каждый раз именно так и пишут. И даже утверждают, что это правильно.
💩43😁19😱15🤬13👍8🤡3❤1
245. Чеклист технического здоровья продукта
В идеальном бирюзовом мире работает так.
Product owner отвечает за продукт, его успешность, фичи, направление развития. Если продукт не нравится пользователям и не приносит денег, овнера бьют по голове канделябром и закапывают в саду.
Dev team отвечает за технику. За стек технологий, поддержку, выплату тех. долга, аптайм. Если сайт упал и лежал два часа, то команду разработки расстреливают в полном составе. А продакту за это ничего не предъявляют, он вообще может сказать, мол, ничего в этом не смыслю, не моя зона ответственности, дайте тоже выстрелить, пожалуйста.
Но то в идеальном бирюзовом мире. Я так работал, но сейчас у меня немного другие реалии. Подозреваю, у многих из вас тоже. И в этих реалиях продакт отвечает в том числе за то, чтобы техника работала сейчас, завтра и через год. Придется разбираться в технике, даже если вы в прошлом дизайнер или маркетолог.
В помощь продуктовым менеджерам небольшой чеклист по технике. Дополняйте в комментариях.
1. Есть мониторинг основных технических характеристика: загрузка серверов, очереди уведомлений, платежей. В идеале – это несколько дашбордов с графиками в реальном времени, например в Grafana.
2. Настроены алерты в телеграм / слак / sms / телефон о серьезных инцидентах. Недоступность продукта с внешнего сервера, не проходит авторизация пользователя, не проходит платеж, не отправляются уведомления пользователям, проблемы с серверами, например закончилось место.
3. Есть тот, кто реагирует на алерты и регулярно смотрит мониторинги. Если у вас тысяча сообщений, которые никто не читает – смысла в них нет.
4. У вас есть бэкапы базы и файлов. Есть доступная всем разработчикам документация, где эти бэкапы лежат.
5. Продукт можно развернуть в полном окружении и работоспособности за сутки. Лучше, за час.
6. У вас есть больше одного человека, кто может поддерживать продукт и восстановить его с нуля. Если у вас всего один разработчик, найдите разработчика на парт-тайм, обучите и пусть он будет за минимальную плату в горячем резерве.
7. Технический долг / проблемы описаны в бэклоге, и существует реалистичный план что и когда с ними делать.
8. У вас не используются языки программирования, фреймворки и библиотеки, на которые сложно найти работников в будущем, когда незаменимый Вася уйдет.
9. Ваши пароли, ключи и доступы хранятся в зашифрованном хранилище. К ним есть доступ не только у разработчиков, но и у менеджера.
10. Есть минимальная документация, с помощью которой посторонний инженер может за день-два разобраться, как работает продукт и начать его поддерживать (или развернуть с нуля).
Если этого нет, то однажды вы можете проснуться и понять, что продукт не работает, чинить его некому, пароли потеряны, а на восстановления контроля вам потребуется два месяца.
В идеальном бирюзовом мире работает так.
Product owner отвечает за продукт, его успешность, фичи, направление развития. Если продукт не нравится пользователям и не приносит денег, овнера бьют по голове канделябром и закапывают в саду.
Dev team отвечает за технику. За стек технологий, поддержку, выплату тех. долга, аптайм. Если сайт упал и лежал два часа, то команду разработки расстреливают в полном составе. А продакту за это ничего не предъявляют, он вообще может сказать, мол, ничего в этом не смыслю, не моя зона ответственности, дайте тоже выстрелить, пожалуйста.
Но то в идеальном бирюзовом мире. Я так работал, но сейчас у меня немного другие реалии. Подозреваю, у многих из вас тоже. И в этих реалиях продакт отвечает в том числе за то, чтобы техника работала сейчас, завтра и через год. Придется разбираться в технике, даже если вы в прошлом дизайнер или маркетолог.
В помощь продуктовым менеджерам небольшой чеклист по технике. Дополняйте в комментариях.
1. Есть мониторинг основных технических характеристика: загрузка серверов, очереди уведомлений, платежей. В идеале – это несколько дашбордов с графиками в реальном времени, например в Grafana.
2. Настроены алерты в телеграм / слак / sms / телефон о серьезных инцидентах. Недоступность продукта с внешнего сервера, не проходит авторизация пользователя, не проходит платеж, не отправляются уведомления пользователям, проблемы с серверами, например закончилось место.
3. Есть тот, кто реагирует на алерты и регулярно смотрит мониторинги. Если у вас тысяча сообщений, которые никто не читает – смысла в них нет.
4. У вас есть бэкапы базы и файлов. Есть доступная всем разработчикам документация, где эти бэкапы лежат.
5. Продукт можно развернуть в полном окружении и работоспособности за сутки. Лучше, за час.
6. У вас есть больше одного человека, кто может поддерживать продукт и восстановить его с нуля. Если у вас всего один разработчик, найдите разработчика на парт-тайм, обучите и пусть он будет за минимальную плату в горячем резерве.
7. Технический долг / проблемы описаны в бэклоге, и существует реалистичный план что и когда с ними делать.
8. У вас не используются языки программирования, фреймворки и библиотеки, на которые сложно найти работников в будущем, когда незаменимый Вася уйдет.
9. Ваши пароли, ключи и доступы хранятся в зашифрованном хранилище. К ним есть доступ не только у разработчиков, но и у менеджера.
10. Есть минимальная документация, с помощью которой посторонний инженер может за день-два разобраться, как работает продукт и начать его поддерживать (или развернуть с нуля).
Если этого нет, то однажды вы можете проснуться и понять, что продукт не работает, чинить его некому, пароли потеряны, а на восстановления контроля вам потребуется два месяца.
🔥74👍11❤4🤩1
0. Чего такой сонный?!
Эй! Да, да, вот ты, подписчик моего канала. Именно ты. Чего такой сонный сегодня?
Погода может быть? Или не выспался? Ну, бывает. Пошли по кофейку бахнем. Или можно китайского чая заварить, у меня есть хороший улун.
А потом за работу. Сейчас день четверга, а не вечер пятницы. Соберись уже!
Эй! Да, да, вот ты, подписчик моего канала. Именно ты. Чего такой сонный сегодня?
Погода может быть? Или не выспался? Ну, бывает. Пошли по кофейку бахнем. Или можно китайского чая заварить, у меня есть хороший улун.
А потом за работу. Сейчас день четверга, а не вечер пятницы. Соберись уже!
❤59🥱12😁9🌚4🥰3🫡3
104. Защитная реакция от приступов ярости
В детстве я был психованным мальчиком. Если не получалось решить задачку по математике, я хлопал дверьми и бросался предметами. Однажды я психанул и сломал стул в своей комнате. С мебелью в Советском Союзе было напряженно, поэтому до конца школы я сидел на сломанном стуле.
Повзрослев я стал веселым, приятным в общении молодым человеком. Но иногда мог вспылить. Ничего страшного, со всеми бывает. Но окружающие имели другую точку зрения. Однажды я запустил настольной лампой в направлении жены. Она посмотрела на меня с таким испугом, что я решил больше так не делать.
В другой раз я разозлился на программистов и проломил гипрочную стену кулаком. Ну подумаешь, не голову же проломил. Однако, коллеги были не согласны с таким подходом. Пришлось долго просить у них прощения и обещать больше ничего не ломать.
Короче, я понял, что агрессия не ведет ни к чему хорошему. Но нелегко обуздать ярость. Я выработал защитную реакцию – я туплю и торможу.
Возвращались с сыном домой на машине. Припарковались, вдруг к нам подбегают два мужика и начинают меня материть. Видимо я их обрызгал, когда проезжал (хотя скорость был близка к нулю и луж не было). Я молчу. Они обзываются и кричат, я молчу. Потом что-то промямлил, мол, не хотел, извините. Они еще поматерили меня и ушли.
Сын говорит: «Пап, чего ты как дебил говорил, ответил бы достойно». Я промычал что-то типа: «да ладно, не важно это». И не стал объяснять ребенку, что пока я мямлил, я боролся с желанием выйти из машины и разбить наглецам голову огнетушителем.
Лучше прослыть тормозом, чем разбираться с последствиями насилия.
#старыйпост
В детстве я был психованным мальчиком. Если не получалось решить задачку по математике, я хлопал дверьми и бросался предметами. Однажды я психанул и сломал стул в своей комнате. С мебелью в Советском Союзе было напряженно, поэтому до конца школы я сидел на сломанном стуле.
Повзрослев я стал веселым, приятным в общении молодым человеком. Но иногда мог вспылить. Ничего страшного, со всеми бывает. Но окружающие имели другую точку зрения. Однажды я запустил настольной лампой в направлении жены. Она посмотрела на меня с таким испугом, что я решил больше так не делать.
В другой раз я разозлился на программистов и проломил гипрочную стену кулаком. Ну подумаешь, не голову же проломил. Однако, коллеги были не согласны с таким подходом. Пришлось долго просить у них прощения и обещать больше ничего не ломать.
Короче, я понял, что агрессия не ведет ни к чему хорошему. Но нелегко обуздать ярость. Я выработал защитную реакцию – я туплю и торможу.
Возвращались с сыном домой на машине. Припарковались, вдруг к нам подбегают два мужика и начинают меня материть. Видимо я их обрызгал, когда проезжал (хотя скорость был близка к нулю и луж не было). Я молчу. Они обзываются и кричат, я молчу. Потом что-то промямлил, мол, не хотел, извините. Они еще поматерили меня и ушли.
Сын говорит: «Пап, чего ты как дебил говорил, ответил бы достойно». Я промычал что-то типа: «да ладно, не важно это». И не стал объяснять ребенку, что пока я мямлил, я боролся с желанием выйти из машины и разбить наглецам голову огнетушителем.
Лучше прослыть тормозом, чем разбираться с последствиями насилия.
#старыйпост
🔥50👍25🤔14💯10🤨4👎2👏2❤1😁1😢1
105. Юзабилити-тестирование для самых маленьких
На прошлой неделе два разных продакта из разных компаний пригласили меня на UX-тестирование в качестве подопытного. Я порадовался, что такие исследования стали популярны. Но оба раза меня ждало разочарование. Оба тестирования начались с показа мне прототипа и вопроса: «Ну как тебе, что скажешь?» Это было настолько неправильно, что я даже растерялся.
Мне неловко писать такие азбучные истины, но видимо нужно. Итак, азы юзабилити-тестирования или UX-тестирования, как его теперь называют:
1. Цель тестирования – найти проблемы в пользовательском интерфейсе, о которых вы знали, но сомневались или о которых даже не подозревали.
2. Сбор фидбэка от пользователей – это вспомогательная активность. Проходит после тестирования.
3. Респонденту надо давать задания, основанные на реальных сценариях. Например: «Вы хотите купить чайник в этом магазине, что вы будете делать?» Вполне вероятно, что в результате вы обнаружите не проблему с покупкой, а проблему с поиском или меню. В этом и суть.
4. Важно, чтобы вопросы не давали подсказки. Плохой пример: «Нажмите на пункт меню “Бытовая техника” и добавьте любой чайник в корзину».
5. Такие исследования – качественные. 5-10 респондентов часто бывает достаточно. Они не отменяют и не заменяют количественные исследования и сбор статистики.
Проводить юзабилити-тестирование достаточно легко. Этому можно быстро научиться. Самый простой способ – напроситься в помощники к опытному специалисту.
#старыйпост
На прошлой неделе два разных продакта из разных компаний пригласили меня на UX-тестирование в качестве подопытного. Я порадовался, что такие исследования стали популярны. Но оба раза меня ждало разочарование. Оба тестирования начались с показа мне прототипа и вопроса: «Ну как тебе, что скажешь?» Это было настолько неправильно, что я даже растерялся.
Мне неловко писать такие азбучные истины, но видимо нужно. Итак, азы юзабилити-тестирования или UX-тестирования, как его теперь называют:
1. Цель тестирования – найти проблемы в пользовательском интерфейсе, о которых вы знали, но сомневались или о которых даже не подозревали.
2. Сбор фидбэка от пользователей – это вспомогательная активность. Проходит после тестирования.
3. Респонденту надо давать задания, основанные на реальных сценариях. Например: «Вы хотите купить чайник в этом магазине, что вы будете делать?» Вполне вероятно, что в результате вы обнаружите не проблему с покупкой, а проблему с поиском или меню. В этом и суть.
4. Важно, чтобы вопросы не давали подсказки. Плохой пример: «Нажмите на пункт меню “Бытовая техника” и добавьте любой чайник в корзину».
5. Такие исследования – качественные. 5-10 респондентов часто бывает достаточно. Они не отменяют и не заменяют количественные исследования и сбор статистики.
Проводить юзабилити-тестирование достаточно легко. Этому можно быстро научиться. Самый простой способ – напроситься в помощники к опытному специалисту.
#старыйпост
👍61💯6❤3
Попросил ребят из Garage Eight рассказать о том, как они проводят продуктовое интервью.
————————————
Продуктовое интервью: что говорить после слова «привет»
Наш продуктовый дизайнер Слава провел более 50 интервью и нащупал свои приемы. Сегодня поговорим о том, как начать разговор.
1. Объясняем суть происходящего. Иногда люди видят слово «интервью» и представляют разговор в духе тех, что печатают в журналах. Важно немного рассказать о себе и о цели происходящего. Я объясняю, что мы хотим понимать проблемы клиентов и их действия в продукте. Тогда человек видит, что не нужно показывать, насколько он супер крут, и расслабляется.
2. Устанавливаем эмоциональный контакт. Чем быстрее человек заговорит, тем быстрее убедится, что его понимают, слушают, что он важен. Плюс так он обозначит комфортный темп беседы. Иногда люди приходят с заготовочкой рассказа о себе. Этот момент нужно «подковырнуть», тогда мы получим возможность задать дополнительные вопросы, зацепиться за тему.
3. Проявляем искреннюю заинтересованность. Спроси, как человек начал пользоваться продуктом. Там всегда есть какая-то история. Копая в личный опыт, задавая вопросы и показывая, что тебе интересно, ты мотивируешь людей вовлекаться и больше рассказывать.
4. Держим в рукаве фреймворк TEDW. Разговорить собеседника помогают «5 почему», переупакованные в 4 фразы:
Tell me more,
Explain me, how/why
Describe me, how/why
Walk me through
Больше подобных тем — на нашем канале @garage_eight
#партнерскийпост
————————————
Продуктовое интервью: что говорить после слова «привет»
Наш продуктовый дизайнер Слава провел более 50 интервью и нащупал свои приемы. Сегодня поговорим о том, как начать разговор.
1. Объясняем суть происходящего. Иногда люди видят слово «интервью» и представляют разговор в духе тех, что печатают в журналах. Важно немного рассказать о себе и о цели происходящего. Я объясняю, что мы хотим понимать проблемы клиентов и их действия в продукте. Тогда человек видит, что не нужно показывать, насколько он супер крут, и расслабляется.
2. Устанавливаем эмоциональный контакт. Чем быстрее человек заговорит, тем быстрее убедится, что его понимают, слушают, что он важен. Плюс так он обозначит комфортный темп беседы. Иногда люди приходят с заготовочкой рассказа о себе. Этот момент нужно «подковырнуть», тогда мы получим возможность задать дополнительные вопросы, зацепиться за тему.
3. Проявляем искреннюю заинтересованность. Спроси, как человек начал пользоваться продуктом. Там всегда есть какая-то история. Копая в личный опыт, задавая вопросы и показывая, что тебе интересно, ты мотивируешь людей вовлекаться и больше рассказывать.
4. Держим в рукаве фреймворк TEDW. Разговорить собеседника помогают «5 почему», переупакованные в 4 фразы:
Tell me more,
Explain me, how/why
Describe me, how/why
Walk me through
Больше подобных тем — на нашем канале @garage_eight
#партнерскийпост
👍24❤6
246. Занимательная арифметика зарплат айтишников
Разберу на примере программиста, но работает для многих – дизайнеров интерфейсов, аналитиков, тестировщиков, менеджеров, маркетологов.
Джун получает 75К, мидл – 150К, синьор – 300К. Очевидно, для простых работ надо использовать джунов, а для чего-то сложного сеньоров. Допустим, надо сделать оплату через новую платежную систему. Не особо сложно, но и не очень легко. Отдаем это мидлу, он работает месяц и стоимость фичи получилась 150К.
Если отдать это синьору, он сделает то же самое за две недели. Потому что половину времени мидл разбирается со сложностями, а сеньор с ними уже разобрался в прошлой жизни. Стоимость фичи в исполнении сеньора также получилась 150К.
Если отдать фичу джуну, он будет долго страдать и сделает за два месяца. Бюджет опять же останется 150К.
Невероятно, но факт: по деньгам все три работника оказались одинаковы. Зато сеньор сэкономил кучу времени всей компании. А еще то, что он сделал, будет проще поддерживать и развивать.
Получается надо брать только сеньоров?
Все не так просто. Суровая реальность не такая занимательная, как арифметика. Есть много других факторов, кроме времени и зарплаты, о которых, возможно, мы поговорим в другой раз.
Разберу на примере программиста, но работает для многих – дизайнеров интерфейсов, аналитиков, тестировщиков, менеджеров, маркетологов.
Джун получает 75К, мидл – 150К, синьор – 300К. Очевидно, для простых работ надо использовать джунов, а для чего-то сложного сеньоров. Допустим, надо сделать оплату через новую платежную систему. Не особо сложно, но и не очень легко. Отдаем это мидлу, он работает месяц и стоимость фичи получилась 150К.
Если отдать это синьору, он сделает то же самое за две недели. Потому что половину времени мидл разбирается со сложностями, а сеньор с ними уже разобрался в прошлой жизни. Стоимость фичи в исполнении сеньора также получилась 150К.
Если отдать фичу джуну, он будет долго страдать и сделает за два месяца. Бюджет опять же останется 150К.
Невероятно, но факт: по деньгам все три работника оказались одинаковы. Зато сеньор сэкономил кучу времени всей компании. А еще то, что он сделал, будет проще поддерживать и развивать.
Получается надо брать только сеньоров?
Все не так просто. Суровая реальность не такая занимательная, как арифметика. Есть много других факторов, кроме времени и зарплаты, о которых, возможно, мы поговорим в другой раз.
👍55🔥14🤔4😁3🐳2🌚2
Пятница подкралась незаметно,
Оставив в прошлом всю неделю,
Ее чудесные деньки,
Что были ясны и легки…
Но вот конец уж на пороге,
Его встречаю я в тревоге,
А в памяти лишь понедельник,
То ли склероз, толь я бездельник.
Пишите в коменты, как прошла неделя у вас. В виде дебильных стишков.
#жизашиза
Оставив в прошлом всю неделю,
Ее чудесные деньки,
Что были ясны и легки…
Но вот конец уж на пороге,
Его встречаю я в тревоге,
А в памяти лишь понедельник,
То ли склероз, толь я бездельник.
Пишите в коменты, как прошла неделя у вас. В виде дебильных стишков.
#жизашиза
🔥9💩3
💩16🌚9👍3😁3🐳2🔥1
Upd: Уже нашел.
Ищу специалиста, кто сможет написать E2E авто тесты на TypeScript. Подойдет QA, кто умеет программировать или фронт-енд разработчик. Работа на несколько месяцев, можно с частичной занятостью. Если кто умеет во фронт и давно хотел научиться писать авто тесты — отличный вариант. Подробное описание:
https://sponsrru.notion.site/Front-end-E2E-042bee1309d44303b5416b85d95c5a50
Шер, репост, дружба, жевачка.
Ищу специалиста, кто сможет написать E2E авто тесты на TypeScript. Подойдет QA, кто умеет программировать или фронт-енд разработчик. Работа на несколько месяцев, можно с частичной занятостью. Если кто умеет во фронт и давно хотел научиться писать авто тесты — отличный вариант. Подробное описание:
https://sponsrru.notion.site/Front-end-E2E-042bee1309d44303b5416b85d95c5a50
Шер, репост, дружба, жевачка.
247. Тут нет дизайна!
Двадцать лет назад я делал сайты. Подолгу сидел подбирал наилучшее решение. Когда спрашивал у знакомых «Как тебе дизайн?», мне часто отвечали: «Тут нет дизайна, обычный сайт». Было обидно, столько труда вложил, а получился «обычный сайт без дизайна».
Потом я стал проектировать платежные интерфейсы и понял, что фраза «тут нет дизайна» – наивысшая похвала. Цель интерфейса – быть незаметным, помогать пользователю достигать целей без отвлечения. Как таблетка, которой не надо давиться, которая легко проскальзывает.
Обычные пользователи замечают интерфейс, когда он им мешает. Если не замечают, если говорят «тут все стандартное» – это показатель отличного дизайна.
Если рядовые пользователи (не коллеги) говорят, что у вас красивый интерфейс, не спешите радоваться, возможно есть проблемы. Лучше, когда «дизайна нет».
Двадцать лет назад я делал сайты. Подолгу сидел подбирал наилучшее решение. Когда спрашивал у знакомых «Как тебе дизайн?», мне часто отвечали: «Тут нет дизайна, обычный сайт». Было обидно, столько труда вложил, а получился «обычный сайт без дизайна».
Потом я стал проектировать платежные интерфейсы и понял, что фраза «тут нет дизайна» – наивысшая похвала. Цель интерфейса – быть незаметным, помогать пользователю достигать целей без отвлечения. Как таблетка, которой не надо давиться, которая легко проскальзывает.
Обычные пользователи замечают интерфейс, когда он им мешает. Если не замечают, если говорят «тут все стандартное» – это показатель отличного дизайна.
Если рядовые пользователи (не коллеги) говорят, что у вас красивый интерфейс, не спешите радоваться, возможно есть проблемы. Лучше, когда «дизайна нет».
👍58🤔7🔥6😁3❤1
Нужен бэкенд / фуллстек на Nodejs
Мне, право, неудобно спамить своими вакансиями. Но загадочным образом они работают, прошлую я закрыл меньше чем за день благодаря вам. Видимо, вы самые лучшие читатели на свете, другого объяснения нет.
Ищу опытного (крепкий мидл и выше) бэкендера на Nodejs. Фулл стека тоже можно, но с упором в бэк. Работать со мной. Я строгий, но справедливый 🙂
https://sponsrru.notion.site/Node-js-Back-end-Full-stack-b0e0a5d272014f1b9666cdca46cf06a5
Приведи друга и получи лучики добра бесплатно.
Мне, право, неудобно спамить своими вакансиями. Но загадочным образом они работают, прошлую я закрыл меньше чем за день благодаря вам. Видимо, вы самые лучшие читатели на свете, другого объяснения нет.
Ищу опытного (крепкий мидл и выше) бэкендера на Nodejs. Фулл стека тоже можно, но с упором в бэк. Работать со мной. Я строгий, но справедливый 🙂
https://sponsrru.notion.site/Node-js-Back-end-Full-stack-b0e0a5d272014f1b9666cdca46cf06a5
Приведи друга и получи лучики добра бесплатно.
😁10