Все бы хорошо, но доступ к материалам курса только на 60 дней - это какое-то ограничение странное. Обычно после покупки курса доступ даётся навсегда и в любое время. Вдруг человек забудет какие-то детали. Решить зайти вспомнить (тем более, что вы пишете об обязательности каждого упражнения), а у него уже доступ к курсу закончился.
Есть конечно и другая сторона: может разработчики все делают и правильно и это такая "игра" в которой выиграет или собственник компании, который хочет "выжать" из сотрудников побольше, заплатив поменьше, а в случае с разработкой ему придется считаться с теми, кого он нанял и он сталкивается с естественным желанием людей работать поменьше, а зарабатывать побольше.
Но в таком случае только один отдел получает выгоду, а остальных ещё сильнее вынуждают работать больше в том числе и компенсировать работу данного отдела.
Сейчас на ресурсе для разработчиков напишу наверное святотатство, но прошу учесть, что это мнение человека, который уже около 13 лет работает в сфере разработки, из них около 7 лет был непосредственно разработчиком, как на бэке, так и на фронте.
У нас часто проблема больше в том, что разработчик для руководства - это такая священная корова.
Что бы он ни делал, ему часто это сходит с рук по причине того, что продукт "держится" на разработке, никто кроме разработчиков не сможет его "починить", никто, кроме них, не знает, как в нем всё устроено.
Если одни разработчики не контролируют других или если у руководства нет такого бекграунда - этот отдел может годами сосать деньги компании, выдавая мизерный результат и прирост к продукту с точки зрения фичей и их качества, при этом потребляя огромное количество финансов компании.
Годами разработчики могут водить за нос руководство и рассказывать, что на фичи, требующие полчаса времени, нужно точно пару месяцев.
Разработчик может полдня где-то гулять (в буквальном смысле, не раз своими глазами видел разработчика, который во время рабочего дня находился не на рабочем месте и при нем не было техники), а потом ночью начинать писать в рабочий и чат об исправленных дефектах, чтобы их проверяли. Или ещё лучше - о фиче, которая уже раскатана в прод.
Кому он там ночью пишет, непонятно.
И это ещё в лучшем случае. У нас годами не исправляются дефекты, которые бесят пользователей, а решаются, при желании, за полчаса. Это моя оценка как человека, который знает, как реализуется фича.
И никто из руководителей этого не видит и не готов поверить, что разработка его дурит. Потому что для него разработка - это магия, если специалист сказал, что на фичу надо два месяца, то так оно, должно быть и есть, он думает. Только другой специалист более высокого уровня (как технического, так и доверия со стороны руководства) сможет доказать, что на нее надо два дня. А ему это надо? Вряд ли - есть много причин, почему не стоит руководству говорить такого.
Я не говорю, что все разработчики такие, но я часто с такими сталкивался и работал с такими в командах. ЧСВ при этом у них выше неба.
Готовность брать на себя ответственность обычно при этом очень низкая. Такое ощущение иногда, что работаешь с капризными детьми из детсада.
Пример: у нас, допустим, разработка постоянно выкатывает фичи с бухты-барахты. Сначала идёт гробовая тишина месяцами в рабочих чатах. Потом бац, прилетает обновление: мы УЖЕ выкатили такое обновление, в котором, например, один критический функционал полностью изменился. После этого от пользователей, которым "без объявления войны" прилетел измененный функционал, которым они на постоянной основе пользуются и который теперь они: не могут найти/понять/разобраться с ним, прилетает ТАКОЙ ФИДБЕК и В ТАКОМ КОЛИЧЕСТВЕ в клиентскую службу, что она просто обтекает сидит.
Потом начинаешь тестировать и понимаешь, почему надо и требования тестировать и UI, и UX. Там такого налеплено, что волосы на голове начинают шевелиться. Дизайнер, такое ощущение, что вообще не пользовался удачными с точки зрения UX продуктами. Механика работы фичи неочевидная (а позже ещё оказывается, когда она ломается, что на её работу нет никакого логирования, при том, что фича - это механизм назначения прав на сущности, например).
Приходишь к продакту, к дизайну, в разработку, говоришь: "Ребята, давайте работать предсказуемее для пользователей как-то. Вот предлагаю такую схему выкатки обновлений, правок (и предлагаешь им стандартное тестирования требований, UX, UI, оповещение пользователей перед релизом, прозрачные механизмы отслеживания, что происходит с тикетами и задачами с ними связанными на всем протяжении ЖЦ обращения).
Но там же у всех ЧСВ, никто не готов признать, что да, текущий процесс косячный и надо поправить.
Продакту в целом пофигу, он говорит: можете с разработкой договориться. Приходишь в разработку, а директор по разработке тебе: "пусть продакт решает, мы на себя не готовы брать ответственность, нам и так все нормально". То есть человек не заинтересован в том, чтобы за счёт процесса сделать работу предсказуемее, прозрачнее, а продукт - качественнее. Он даже за ту часть процесса, которая находится на его участке работы, не готов взять ответственность.
И как QA, поддержка должны работать с такими отделами?
На мой взгляд частенько отдел разработки в компании - это такой капризный ребенок: надо, чтобы под него все подстраивались, компенсировали его недоработки, не указывали на ошибки, при этом его кормили, холили и лелеяли. Он всячески будет с себя снимать ответственность, работу и перекладывать её на других и ему за это ничего не будет.
Или более простой пример: разработка выкатывает фичу.
Начинаешь проверять и такое ощущение, что они просто написали код и отправили его в прод вообще ни разу не запустив и не проверив в интерфейсе.
Почему я так думаю?
Потому что дефект находится в самом явном месте в данном функционале. Ничего не надо: ни каких-то особых условий воспроизведения, ни настроек среды. Просто проходишь по самому первому позитивному сценарию.
Я не говорю, что разработчики должны полностью тестировать выпускаемый функционал (про TDD скромно умолчим тут), речь про то, что хотя бы один раз наверное надо запустить и пройти по позитивному сценарию проверки, иначе как ты вообще понимаешь, что твоя фича работает?
Если я, "кнопкодав", нашел это спустя минуту после того как "профессор разработчик" пару месяцев над этим ленился трудился. То вопросов больше, чем ответов.
Часто фичи выдаются вообще без какого-либо описания, типа как "нате, сами разберётесь". Начинаешь уточнять, молчат. Или стандартная ерунда: в пятницу вечером выкатывать релиз, при том, что ты знаешь: пользователи твоего продукта активно РАБОТАЮТ в субботу и воскресенье, а ещё ты знаешь, что точно будут дефекты. О каком work-life балансе может идти речь в таком сценарии? И вот вы вечером в пятницу ищите дефекты, потом отвечаете пользователям в выходные, а в голове в этот момент у вас картинка о разработчике, которого вы в среду днём видели гуляющего. Ну просто вот ему удобно работать ночью или вечером и ему руководство позволяет так делать, потому что боится, что он уйдет и потом ещё больше придется тратить на поиск ещё одного такого же, и потому что бас-фактор же.
Коммуникация с разработкой, это отдельная история: ты им отвечаешь в течение минуты после вопроса, они тебе могут пару дней спокойно ничего не отвечать. И руководство реально смотрит на это сквозь пальцы, потому что это такая каста "неприкасаемых".
Вот и вся история про процессы и некоторые из причин, почему они ломаются и почему QA выгорают.
Я думаю все очень зависит от команды разработки, если там ответственные взрослые люди работают, то и процессы будут выстроены нормально, при желании остальных и наличии политической воли руководства компании.
Если же у тебя детсад в разработке, а руководство ничего с этим сделать не может, то оно все будет работать через пень-колоду и все будут выгорать.
Это те самые галеры, на которых если кто-то не гребёт, остальным приходится грести за него, чтобы эта лодка худо-бедно плыла дальше.
Кто-то может поспорить думаю, но повторюсь речь не шла о всех разработчиков, кто-то себя в этом не узнает.
Думаю возможно это одна из причин массовых сокращений, которые сейчас идут в индустрии. Как раз вот таких сотрудников, которых я выше описал, видимо и сокращают.
В целом логично проводить именно такое, а не полагаться на память клиентов и своими глазами видеть, как они взаимодействуют с интерфейсом.
Правда проблема в том, что это надо чтобы много звёзд сошлось: пользователи, готовые тратить на это время, ресурсы у компании для проведения таких исследований.
В целом статья полезная, но конкретно этот тип исследования пользовательского поведения, если я верно помню, описан у Стивена Круга, в книге "Не заставляйте меня думать", которую некоторые считают базой в сфере UX. Не понял, чем такое исследование отличается от описанного у него.
Прекрасная статья. Нахожусь в проекте, где пренебрегли практически всеми этими советами.
И теперь мы на грани банкротства: отвалились все клиенты, уволились все сотрудники, кто хоть в чем-то разбирался нормально.
Я остался только для того, чтобы убедиться, что все закончится именно так, как я ожидал ещё года 2 назад и чтобы получить этот опыт "прохождения" всех этапов ЖЦ организации, вплоть до её ликвидации.
Один из самых важных советов здесь: про поддержание качества. А ключевая фраза, что когда его нет - это сразу видно, а когда оно есть, то никто часто не понимает, что его надо поддерживать и выделять на это ресурсы.
Клиенты и пользователи обязательно уйдут, если люди, ставящие задачи разработке, не понимают этого.
Мне как-то начальник сказал умную вещь и я с ним согласен: "Кому что-то критичнее и важнее, тот и должен шевелиться".
Пример: вы заказываете какую-то услугу. Кто заинтересован получить качественную услугу? Вы.
Исполнителю услуги важнее получить с вас деньги и чтобы поменьше с вашей стороны было требований. Желательно вообще, чтобы он выполнил услугу по минимуму (с минимальной затратой ресурсов) или вообще не работал, а вы заплатили (и, желательно, побольше).
Соответственно это вам надо держать исполнителя в тонусе, чтобы он не расслаблял булки и делал качественно. Потому что вам это важнее.
В кейсе, например, про начальника с пассивной агрессией, именно сотруднику важнее не работать в токсичной атмосфере и прояснить, почему на него начальник злится. Поэтому сотрудник подходит и говорит: "Тебя что-то не устраивает в моей работе? Почему такое отношение? Хочешь в бубен? (шутка)". Если начальник пошлёт, значит надо перестать быть подчинённым этого начальника. Тем или иным способом)). А не хавать его агрессию и вымещать её на других, например, или зарабатывать психосоматическое заболевание.
У меня была ситуация, когда начальник начал какие-то шутки непонятные шутить в мою сторону. Я его так и спросил: "Тебя что-то не устраивает во мне или в моей работе? Я таких шуток не понимаю. Ты меня как-то задеть ими хочешь?" .
Мы с ним поговорили и он извинился, сказал, что не думал, что меня это задевает. Больше так не шутил.
Насчёт "говорить ртом" - это правда полезный навык. Просто надо понимать, когда так делать - улучшит твою жизнь, а когда нет )).
В целом описанная методика интересна, есть над чем подумать. Если результаты действительно такие, как написано - тем более.
Но, смутило вот это:
Самому выбивать ресурсы у других продуктовых команд
Убеждать стейкхолдеров в ценности направления
У меня есть на этот счёт классное выражение от знакомого руководителя:
Вместе с обязанностями должны даваться и полномочия.
В вашей формулировке (может, конечно, формулировка не отражает того, что вы хотели сказать, но я так понял) я вижу противоположную картину:
Он:
1) Должен был "выбивать" ресурсы для реализации замысла.
Давайте представим в вашу команду приходит человек, у которого нет никаких полномочий и рычагов давления на вас (это из формулировки что ему надо было убеждать стейкхолдеров в ценности его направления) и говорит: "выдели мне одного программиста". Вы, зная, что вам за это ничего не будет, что скажете? "Пожалуйста, бери и гори огнем мои дедлайна?" Сомневаюсь.
Это как нанять дворника и сказать: "Ты отвечаешь за чистоту двора". Но каждый раз, когда он придет во двор прибраться, выгонять его и говорить: "У тебя нет полномочий тут находится и что-то делать".
По поводу стейкхолдеров: любой проект изменений, к которым в какой-то степени можно отнести описанную вами ситуацию, требует заинтересованности стейкхолдеров. Когда её нет - человек, тем более без полномочий, сделать ничего не сможет и ничего нового не затащит.
Заинтересованность в проекте ключевых ЛПР и стейкхолдеров и есть тот рычаг, через который ПМ может реализовать свои полномочия и добиваться чего-то от людей, которые не находятся в прямом подчинении у него.
Сама предпосылка статьи в виде этого примера некорректна, на мой взгляд.
Но, сама методика подбора интересна для ознакомления.
Сегодня прочитал про ошибки в резюме. Якобы рекрутеры зря такие резюме сразу отклоняют. Там в статье приводился интересный факт, что во время проверки собственного текста мы можем не увидеть ошибок из-за некоего феномена работы мозга: якобы написанное "соревнуется" с тем, что мы представляем в голове и не всегда выиграет, якобы мы видим то, что хотим увидеть (не проверял этот факт, поэтому возможно это вранье). Из-за чего при вычитке легко можно пропустить ошибку.
Узнав это, стал проще относиться к чужим ошибкам.
Замечал не раз, что чужие ошибки намного проще в тексте находить, чем свои собственные. Бывает проверишь на 3 раза текст, а в итоге все равно где-то или опечатку пропустишь, либо ошибку, либо запятую.
Ошибки не раздражают в тех случаях, когда они на тебя никак не влияют. Но когда, к примеру, их надо постоянно исправлять за кем-то (не являясь корректором или редактором, просто по ходу основной работы), - это иногда начинает раздражать.
Да не, бывает такое. В одном месте устраивался - устроили стресс-интервью. Я сначала не понял, что за дичь началась, потом послал их нафиг и только по дороге домой понял, что это было оно.
Про зарплату и то, что кто-то думает, что сотрудник должен быть амбассадором компании всегда удивляло.
Люди приходят на работу заработать денег на свою жизнь, компании, примите вы уже это.
Для вас сотрудник - это ресурс, инструмент. Не больше и не меньше.
Вы же не просите молоток испытывать к вам чувства? Вы его покупаете и он вам какое-то время служит.
Вся эта требуемая лояльность к компании должна быть исключительно по желанию или ради профессиональных каких-то устремлений человека. То есть он работу делает классно не потому что любит вашу компанию, вас, как руководителя, а потому что он профессионал и хочет делать свою работу хорошо, ответственно, профессионально расти.
Часто вся эта лояльность играет только против сотрудников, которые ее проявляют. Допустим человек болеет за продукт, его качество, сервис, репутацию компании, а вы, как руководитель, допустим, преследуете другие цели: вам этот продукт, качеством ниже среднего, надо просто продать побольше и получить прибыль. Вам вообще эти траты на качество, репутацию и т.д. никуда не уперлись, ибо снижают вашу прибыль. И что тогда? Сотрудник придет с верой в профессионализм, а уйдет выгоревшим бунтарем против политики компании, разочаровавшись в руководстве и компании.
Пусть компанию любит ее создатель, пусть он упивается наполеоновскими планами на нее, а сотрудникам просто платите деньги за работу если она вас устраивает, не надо их в свою веру заманивать, это не их компания, это ваша компания.
Я вот тоже был когда помладше, спорил, что-то доказывал, отстаивал свою точку зрения. А потом в какой-то момент понял: а зачем мне это надо? Это не моя компания, не я распоряжаюсь деньгами, каждый очет как хочет. Ну хочет руководитель все пустить коту под хвост - так и пусть пускает: его компания, его деньги. Я как профессионал свои опасения все могу высказать, а решать-то все равно ему. Не слушает, ну и фиг бы с ним.
Сегодня побывал на первом таком интервью. Слышал о них до этого, но как-то не вспомнил в процессе. Учитывая то, что hr-ов не переношу на дух, а тут ещё и hr начал выделывается. Я думаю, что с таких интервью надо уходить просто. Везде пишут: ведите себя спокойно, прогибайтесь, пусть вас унижают, не отвечайте. Это бред какой-то, человек задевает твое человеческое достоинство, а ты должен перед ним хвостиком вилять? Думаю, что надо быть конченым идиотом, чтобы оставаться работать в такой компании.
Вообще, проблема читалок в передаче изображений, масштабировании, если читать скан: DjVu или Pdf, то с читалки это делать… про это даже кино снято и книга написана «50 оттенков серого» называется.
Ну вот как раз у меня так и произошло, я пополнил счёт в конце месяца, а у них шла акция пополни счёт, а мы тебе услугу подключим. И они списывают в минус даже, так что 0 на счету не помог бы.
Ну хз, по мне так одна из самых удачных моделей у Xiaomi — Redmi 4X 32gb 3gb. Почему с ней не сравнили? Батарея больше чем в 5ом. Диагональ экрана меньше — для меня лично это большой плюс. Я купил себе этот телефон, потом друг спросил, что за тел у меня и купил такой же, потом друг жене купил такой же, а пару дней назад я купил жене по ее просьбе такой же. Видите, увеличения сбыта можно достигать не только количеством вхождений названия тела в текст, но и тупо хорошим качеством. Если аппарат рабочий, не глючит, имеет нормальную оболочку и вы не собираетесь на нем в космос летать, то зачем вам эти цифры все?
Если ответить кратко на вопрос, почему мне нравятся больше бумажные книги:
Потому что книга — это вещь (во всех смыслах этого слова)
А если чуть более развернуто: сейчас приходит в голову спектакль Евгения Гришковца «Прощание с бумагой». Там он говорит о цифровой фотографии в частности и о том, что не хочется думать про любимые лица родных на фото, что это последовательность нулей и единиц. Не смотря на то, что по сути, содержание электронной книги и бумажной особо не отличается, первая кажется мне какой-то пустышкой, на подсознательном уровне, вторую же тактильно приятно держать, она приятно пахнет, это будто кусочек истории в руках и в целом от нее только положительные эмоции.
Вот с удовольствием бы затеял эту процедуру, но, может в силу неосведомленности, ни разу не слышал о возмещении кому-либо такого морального ущерба в РФ. А так, конечно было бы замечательно: этакий супергерой, призываешь к ответу подлецов, да еще и можно после этого в свою собственную квартиру переехать и людям-то хорошо, оператор их обманывать не будет. Жаль это видится чем-то вроде фантастики. Хотя если найдется юрист…
Да, все верно, можно было избежать этого, если бы первое сообщение читалось однозначно.
Но заметьте, нигде ни в каком сообщении не указано, что услуга будет подключена автоматически при пополнении счета. Я лично не верил в возможность того, что услугу мне подключат сразу при пополнении счета без моего участия и воспринял это, как уведомление о том, что можно будет подключить эту услугу бесплатно на 7 дней (то что акция именно о том, что если я пополню в этот день, то подключив сам услугу смогу неделю пользоваться ей бесплатно).
Потом можно еще подумать, что да, они подключают услугу при пополнении и дают попользоваться ею бесплатно 7 дней, после чего, если понравилась услуга, то можешь ее продлить, сам заказав ее. В общем, просто я не ожидал, что оператор может вот так вот просто сам подключить мне услугу и снимать за нее деньги, по-моему это наглость, какую еще поискать надо.
И заметьте, когда пришло уведомление о подключении услуги, там написано «Акция закачай и прокачай» или что-то типа того, никакого «беспредельного интернета» и «безлимитного интернета». То есть даже не понятно, то ли я подключил что-то, то ли просто стал участником акции по каким-то критериям.
Рад, что помог вам заметить. Я попросил отключить у меня все возможности без моего ведома подключать мне что-то. Заверили, что больше такого не повторится.
Все бы хорошо, но доступ к материалам курса только на 60 дней - это какое-то ограничение странное. Обычно после покупки курса доступ даётся навсегда и в любое время. Вдруг человек забудет какие-то детали. Решить зайти вспомнить (тем более, что вы пишете об обязательности каждого упражнения), а у него уже доступ к курсу закончился.
Есть конечно и другая сторона: может разработчики все делают и правильно и это такая "игра" в которой выиграет или собственник компании, который хочет "выжать" из сотрудников побольше, заплатив поменьше, а в случае с разработкой ему придется считаться с теми, кого он нанял и он сталкивается с естественным желанием людей работать поменьше, а зарабатывать побольше.
Но в таком случае только один отдел получает выгоду, а остальных ещё сильнее вынуждают работать больше в том числе и компенсировать работу данного отдела.
Сейчас на ресурсе для разработчиков напишу наверное святотатство, но прошу учесть, что это мнение человека, который уже около 13 лет работает в сфере разработки, из них около 7 лет был непосредственно разработчиком, как на бэке, так и на фронте.
У нас часто проблема больше в том, что разработчик для руководства - это такая священная корова.
Что бы он ни делал, ему часто это сходит с рук по причине того, что продукт "держится" на разработке, никто кроме разработчиков не сможет его "починить", никто, кроме них, не знает, как в нем всё устроено.
Если одни разработчики не контролируют других или если у руководства нет такого бекграунда - этот отдел может годами сосать деньги компании, выдавая мизерный результат и прирост к продукту с точки зрения фичей и их качества, при этом потребляя огромное количество финансов компании.
Годами разработчики могут водить за нос руководство и рассказывать, что на фичи, требующие полчаса времени, нужно точно пару месяцев.
Разработчик может полдня где-то гулять (в буквальном смысле, не раз своими глазами видел разработчика, который во время рабочего дня находился не на рабочем месте и при нем не было техники), а потом ночью начинать писать в рабочий и чат об исправленных дефектах, чтобы их проверяли. Или ещё лучше - о фиче, которая уже раскатана в прод.
Кому он там ночью пишет, непонятно.
И это ещё в лучшем случае. У нас годами не исправляются дефекты, которые бесят пользователей, а решаются, при желании, за полчаса. Это моя оценка как человека, который знает, как реализуется фича.
И никто из руководителей этого не видит и не готов поверить, что разработка его дурит. Потому что для него разработка - это магия, если специалист сказал, что на фичу надо два месяца, то так оно, должно быть и есть, он думает. Только другой специалист более высокого уровня (как технического, так и доверия со стороны руководства) сможет доказать, что на нее надо два дня. А ему это надо? Вряд ли - есть много причин, почему не стоит руководству говорить такого.
Я не говорю, что все разработчики такие, но я часто с такими сталкивался и работал с такими в командах. ЧСВ при этом у них выше неба.
Готовность брать на себя ответственность обычно при этом очень низкая. Такое ощущение иногда, что работаешь с капризными детьми из детсада.
Пример: у нас, допустим, разработка постоянно выкатывает фичи с бухты-барахты. Сначала идёт гробовая тишина месяцами в рабочих чатах. Потом бац, прилетает обновление: мы УЖЕ выкатили такое обновление, в котором, например, один критический функционал полностью изменился. После этого от пользователей, которым "без объявления войны" прилетел измененный функционал, которым они на постоянной основе пользуются и который теперь они: не могут найти/понять/разобраться с ним, прилетает ТАКОЙ ФИДБЕК и В ТАКОМ КОЛИЧЕСТВЕ в клиентскую службу, что она просто обтекает сидит.
Потом начинаешь тестировать и понимаешь, почему надо и требования тестировать и UI, и UX. Там такого налеплено, что волосы на голове начинают шевелиться. Дизайнер, такое ощущение, что вообще не пользовался удачными с точки зрения UX продуктами. Механика работы фичи неочевидная (а позже ещё оказывается, когда она ломается, что на её работу нет никакого логирования, при том, что фича - это механизм назначения прав на сущности, например).
Приходишь к продакту, к дизайну, в разработку, говоришь: "Ребята, давайте работать предсказуемее для пользователей как-то. Вот предлагаю такую схему выкатки обновлений, правок (и предлагаешь им стандартное тестирования требований, UX, UI, оповещение пользователей перед релизом, прозрачные механизмы отслеживания, что происходит с тикетами и задачами с ними связанными на всем протяжении ЖЦ обращения).
Но там же у всех ЧСВ, никто не готов признать, что да, текущий процесс косячный и надо поправить.
Продакту в целом пофигу, он говорит: можете с разработкой договориться. Приходишь в разработку, а директор по разработке тебе: "пусть продакт решает, мы на себя не готовы брать ответственность, нам и так все нормально". То есть человек не заинтересован в том, чтобы за счёт процесса сделать работу предсказуемее, прозрачнее, а продукт - качественнее. Он даже за ту часть процесса, которая находится на его участке работы, не готов взять ответственность.
И как QA, поддержка должны работать с такими отделами?
На мой взгляд частенько отдел разработки в компании - это такой капризный ребенок: надо, чтобы под него все подстраивались, компенсировали его недоработки, не указывали на ошибки, при этом его кормили, холили и лелеяли. Он всячески будет с себя снимать ответственность, работу и перекладывать её на других и ему за это ничего не будет.
Или более простой пример: разработка выкатывает фичу.
Начинаешь проверять и такое ощущение, что они просто написали код и отправили его в прод вообще ни разу не запустив и не проверив в интерфейсе.
Почему я так думаю?
Потому что дефект находится в самом явном месте в данном функционале. Ничего не надо: ни каких-то особых условий воспроизведения, ни настроек среды. Просто проходишь по самому первому позитивному сценарию.
Я не говорю, что разработчики должны полностью тестировать выпускаемый функционал (про TDD скромно умолчим тут), речь про то, что хотя бы один раз наверное надо запустить и пройти по позитивному сценарию проверки, иначе как ты вообще понимаешь, что твоя фича работает?
Если я, "кнопкодав", нашел это спустя минуту после того как "профессор разработчик" пару месяцев над этим
ленилсятрудился. То вопросов больше, чем ответов.Часто фичи выдаются вообще без какого-либо описания, типа как "нате, сами разберётесь". Начинаешь уточнять, молчат. Или стандартная ерунда: в пятницу вечером выкатывать релиз, при том, что ты знаешь: пользователи твоего продукта активно РАБОТАЮТ в субботу и воскресенье, а ещё ты знаешь, что точно будут дефекты. О каком work-life балансе может идти речь в таком сценарии? И вот вы вечером в пятницу ищите дефекты, потом отвечаете пользователям в выходные, а в голове в этот момент у вас картинка о разработчике, которого вы в среду днём видели гуляющего. Ну просто вот ему удобно работать ночью или вечером и ему руководство позволяет так делать, потому что боится, что он уйдет и потом ещё больше придется тратить на поиск ещё одного такого же, и потому что бас-фактор же.
Коммуникация с разработкой, это отдельная история: ты им отвечаешь в течение минуты после вопроса, они тебе могут пару дней спокойно ничего не отвечать. И руководство реально смотрит на это сквозь пальцы, потому что это такая каста "неприкасаемых".
Вот и вся история про процессы и некоторые из причин, почему они ломаются и почему QA выгорают.
Я думаю все очень зависит от команды разработки, если там ответственные взрослые люди работают, то и процессы будут выстроены нормально, при желании остальных и наличии политической воли руководства компании.
Если же у тебя детсад в разработке, а руководство ничего с этим сделать не может, то оно все будет работать через пень-колоду и все будут выгорать.
Это те самые галеры, на которых если кто-то не гребёт, остальным приходится грести за него, чтобы эта лодка худо-бедно плыла дальше.
Кто-то может поспорить думаю, но повторюсь речь не шла о всех разработчиков, кто-то себя в этом не узнает.
Думаю возможно это одна из причин массовых сокращений, которые сейчас идут в индустрии. Как раз вот таких сотрудников, которых я выше описал, видимо и сокращают.
В целом логично проводить именно такое, а не полагаться на память клиентов и своими глазами видеть, как они взаимодействуют с интерфейсом.
Правда проблема в том, что это надо чтобы много звёзд сошлось: пользователи, готовые тратить на это время, ресурсы у компании для проведения таких исследований.
В целом статья полезная, но конкретно этот тип исследования пользовательского поведения, если я верно помню, описан у Стивена Круга, в книге "Не заставляйте меня думать", которую некоторые считают базой в сфере UX. Не понял, чем такое исследование отличается от описанного у него.
Прекрасная статья. Нахожусь в проекте, где пренебрегли практически всеми этими советами.
И теперь мы на грани банкротства: отвалились все клиенты, уволились все сотрудники, кто хоть в чем-то разбирался нормально.
Я остался только для того, чтобы убедиться, что все закончится именно так, как я ожидал ещё года 2 назад и чтобы получить этот опыт "прохождения" всех этапов ЖЦ организации, вплоть до её ликвидации.
Один из самых важных советов здесь: про поддержание качества. А ключевая фраза, что когда его нет - это сразу видно, а когда оно есть, то никто часто не понимает, что его надо поддерживать и выделять на это ресурсы.
Клиенты и пользователи обязательно уйдут, если люди, ставящие задачи разработке, не понимают этого.
А как получить эти годы практики, если не пробовать усилием воли говорить, когда нужно говорить?
Сначала говорить в том кругу, где более комфортно и тебя по-умолчанию принимают, потом говорить на более широкие массы.
К сожалению, единственный путь научиться что-то делать - это делать это.
Мне как-то начальник сказал умную вещь и я с ним согласен: "Кому что-то критичнее и важнее, тот и должен шевелиться".
Пример: вы заказываете какую-то услугу. Кто заинтересован получить качественную услугу? Вы.
Исполнителю услуги важнее получить с вас деньги и чтобы поменьше с вашей стороны было требований. Желательно вообще, чтобы он выполнил услугу по минимуму (с минимальной затратой ресурсов) или вообще не работал, а вы заплатили (и, желательно, побольше).
Соответственно это вам надо держать исполнителя в тонусе, чтобы он не расслаблял булки и делал качественно. Потому что вам это важнее.
В кейсе, например, про начальника с пассивной агрессией, именно сотруднику важнее не работать в токсичной атмосфере и прояснить, почему на него начальник злится. Поэтому сотрудник подходит и говорит: "Тебя что-то не устраивает в моей работе? Почему такое отношение? Хочешь в бубен? (шутка)". Если начальник пошлёт, значит надо перестать быть подчинённым этого начальника. Тем или иным способом)). А не хавать его агрессию и вымещать её на других, например, или зарабатывать психосоматическое заболевание.
У меня была ситуация, когда начальник начал какие-то шутки непонятные шутить в мою сторону. Я его так и спросил: "Тебя что-то не устраивает во мне или в моей работе? Я таких шуток не понимаю. Ты меня как-то задеть ими хочешь?" .
Мы с ним поговорили и он извинился, сказал, что не думал, что меня это задевает. Больше так не шутил.
Насчёт "говорить ртом" - это правда полезный навык. Просто надо понимать, когда так делать - улучшит твою жизнь, а когда нет )).
В целом описанная методика интересна, есть над чем подумать. Если результаты действительно такие, как написано - тем более.
Но, смутило вот это:
У меня есть на этот счёт классное выражение от знакомого руководителя:
В вашей формулировке (может, конечно, формулировка не отражает того, что вы хотели сказать, но я так понял) я вижу противоположную картину:
Он:
1) Должен был "выбивать" ресурсы для реализации замысла.
Давайте представим в вашу команду приходит человек, у которого нет никаких полномочий и рычагов давления на вас (это из формулировки что ему надо было убеждать стейкхолдеров в ценности его направления) и говорит: "выдели мне одного программиста". Вы, зная, что вам за это ничего не будет, что скажете? "Пожалуйста, бери и гори огнем мои дедлайна?" Сомневаюсь.
Это как нанять дворника и сказать: "Ты отвечаешь за чистоту двора". Но каждый раз, когда он придет во двор прибраться, выгонять его и говорить: "У тебя нет полномочий тут находится и что-то делать".
По поводу стейкхолдеров: любой проект изменений, к которым в какой-то степени можно отнести описанную вами ситуацию, требует заинтересованности стейкхолдеров. Когда её нет - человек, тем более без полномочий, сделать ничего не сможет и ничего нового не затащит.
Заинтересованность в проекте ключевых ЛПР и стейкхолдеров и есть тот рычаг, через который ПМ может реализовать свои полномочия и добиваться чего-то от людей, которые не находятся в прямом подчинении у него.
Сама предпосылка статьи в виде этого примера некорректна, на мой взгляд.
Но, сама методика подбора интересна для ознакомления.
Подскажите, пожалуйста, есть ли у вас API, который принимал бы видеопоток и генерировал, к примеру, переведенную речь? Где можно почитать о нем?
Сегодня прочитал про ошибки в резюме. Якобы рекрутеры зря такие резюме сразу отклоняют. Там в статье приводился интересный факт, что во время проверки собственного текста мы можем не увидеть ошибок из-за некоего феномена работы мозга: якобы написанное "соревнуется" с тем, что мы представляем в голове и не всегда выиграет, якобы мы видим то, что хотим увидеть (не проверял этот факт, поэтому возможно это вранье). Из-за чего при вычитке легко можно пропустить ошибку.
Узнав это, стал проще относиться к чужим ошибкам.
Замечал не раз, что чужие ошибки намного проще в тексте находить, чем свои собственные. Бывает проверишь на 3 раза текст, а в итоге все равно где-то или опечатку пропустишь, либо ошибку, либо запятую.
Ошибки не раздражают в тех случаях, когда они на тебя никак не влияют. Но когда, к примеру, их надо постоянно исправлять за кем-то (не являясь корректором или редактором, просто по ходу основной работы), - это иногда начинает раздражать.
Да не, бывает такое. В одном месте устраивался - устроили стресс-интервью. Я сначала не понял, что за дичь началась, потом послал их нафиг и только по дороге домой понял, что это было оно.
Про зарплату и то, что кто-то думает, что сотрудник должен быть амбассадором компании всегда удивляло.
Люди приходят на работу заработать денег на свою жизнь, компании, примите вы уже это.
Для вас сотрудник - это ресурс, инструмент. Не больше и не меньше.
Вы же не просите молоток испытывать к вам чувства? Вы его покупаете и он вам какое-то время служит.
Вся эта требуемая лояльность к компании должна быть исключительно по желанию или ради профессиональных каких-то устремлений человека. То есть он работу делает классно не потому что любит вашу компанию, вас, как руководителя, а потому что он профессионал и хочет делать свою работу хорошо, ответственно, профессионально расти.
Часто вся эта лояльность играет только против сотрудников, которые ее проявляют. Допустим человек болеет за продукт, его качество, сервис, репутацию компании, а вы, как руководитель, допустим, преследуете другие цели: вам этот продукт, качеством ниже среднего, надо просто продать побольше и получить прибыль. Вам вообще эти траты на качество, репутацию и т.д. никуда не уперлись, ибо снижают вашу прибыль. И что тогда? Сотрудник придет с верой в профессионализм, а уйдет выгоревшим бунтарем против политики компании, разочаровавшись в руководстве и компании.
Пусть компанию любит ее создатель, пусть он упивается наполеоновскими планами на нее, а сотрудникам просто платите деньги за работу если она вас устраивает, не надо их в свою веру заманивать, это не их компания, это ваша компания.
Я вот тоже был когда помладше, спорил, что-то доказывал, отстаивал свою точку зрения. А потом в какой-то момент понял: а зачем мне это надо? Это не моя компания, не я распоряжаюсь деньгами, каждый очет как хочет. Ну хочет руководитель все пустить коту под хвост - так и пусть пускает: его компания, его деньги. Я как профессионал свои опасения все могу высказать, а решать-то все равно ему. Не слушает, ну и фиг бы с ним.
Спасибо, теперь знаю, что не только я так думаю.
Сегодня побывал на первом таком интервью. Слышал о них до этого, но как-то не вспомнил в процессе. Учитывая то, что hr-ов не переношу на дух, а тут ещё и hr начал выделывается. Я думаю, что с таких интервью надо уходить просто. Везде пишут: ведите себя спокойно, прогибайтесь, пусть вас унижают, не отвечайте. Это бред какой-то, человек задевает твое человеческое достоинство, а ты должен перед ним хвостиком вилять? Думаю, что надо быть конченым идиотом, чтобы оставаться работать в такой компании.
Ну вот как раз у меня так и произошло, я пополнил счёт в конце месяца, а у них шла акция пополни счёт, а мы тебе услугу подключим. И они списывают в минус даже, так что 0 на счету не помог бы.
Потому что книга — это вещь (во всех смыслах этого слова)
А если чуть более развернуто: сейчас приходит в голову спектакль Евгения Гришковца «Прощание с бумагой». Там он говорит о цифровой фотографии в частности и о том, что не хочется думать про любимые лица родных на фото, что это последовательность нулей и единиц. Не смотря на то, что по сути, содержание электронной книги и бумажной особо не отличается, первая кажется мне какой-то пустышкой, на подсознательном уровне, вторую же тактильно приятно держать, она приятно пахнет, это будто кусочек истории в руках и в целом от нее только положительные эмоции.
Но заметьте, нигде ни в каком сообщении не указано, что услуга будет подключена автоматически при пополнении счета. Я лично не верил в возможность того, что услугу мне подключат сразу при пополнении счета без моего участия и воспринял это, как уведомление о том, что можно будет подключить эту услугу бесплатно на 7 дней (то что акция именно о том, что если я пополню в этот день, то подключив сам услугу смогу неделю пользоваться ей бесплатно).
Потом можно еще подумать, что да, они подключают услугу при пополнении и дают попользоваться ею бесплатно 7 дней, после чего, если понравилась услуга, то можешь ее продлить, сам заказав ее. В общем, просто я не ожидал, что оператор может вот так вот просто сам подключить мне услугу и снимать за нее деньги, по-моему это наглость, какую еще поискать надо.
И заметьте, когда пришло уведомление о подключении услуги, там написано «Акция закачай и прокачай» или что-то типа того, никакого «беспредельного интернета» и «безлимитного интернета». То есть даже не понятно, то ли я подключил что-то, то ли просто стал участником акции по каким-то критериям.