Показаны сообщения с ярлыком вопрос. Показать все сообщения
Показаны сообщения с ярлыком вопрос. Показать все сообщения

пятница, 23 марта 2018 г.

Открывая организации будущего, часть вторая

Продолжаю читать книгу Лалу.

Поехали.
Компании, чья работа включает множество проектов, пересматривают и архи-
тектуру своих рабочих помещений. Офис в Sun Hydraulics — это большое открытое пространство со специально разработанными кабинками. Стены на уровне пояса.
Одним взглядом можно определить, кто на месте, и услышать сразу множество разговоров. Это значительно улучшает сотрудничество, отмечают коллеги. Множество вопросов, которые в другой компании привели бы к долгой электронной переписке или назначению встреч, теперь решаются просто в разговоре с коллегой через стенку кабинки.
Это ужас, ад и Израиль. Шум, отвлечения и прочие атрибуты опенспейса. Читайте Шаблоны проектирования Александера и Peopleware Демарко.

И компания ввела «правило 80–20»: каждый сотрудник AES, от уборщицы до инженера, в среднем обязан 80% рабочего времени посвящать основным обязанностям и быть готов присоединиться к одной или нескольким рабочим группам в остальные 20% времени.
Мне нравится, но непонятно, как решается вопрос недопроизводства в основной работе. IT - отрасль с избытком задач, всегда можно и иногда нужно и гораздо чаще хочется  сделать больше. А тут какие-то 20%... К тому же "интерес" у человека один и не делится на проценты.

Процесс внутреннего консультирования идет снизу вверх, но идет не на авось и не по принципу «будь что будет». Он включает творческий дух, взвешенный анализ, тщательное планирование и дисциплинированное исполнение.
И благолепие настает само! Тут же все становятся умными и дисциплинированными. Всегда. Ага.
В Buurtzorg все данные относительно производительности команд выкладываются во внутреннюю сеть.
Удобно, когда производительность можно сравнить. Один тестер написал 10 тестов за неделю, второй сделал так, что верстку проверил проектировщик и не тратил ни минуты.
Один месяц гонял регрессию и ненавидит работу, второй три дня писал тесты, с которыми потом все задолбаются...

Что и с чем тут сравнивать?

Планирование преемственности — еще одна установившаяся практика HR-службы. Для каждого руководителя в компании подыскивается и воспитывается возможный преемник. И, наконец, существует процесс планирования карьеры
Это то, чем нужно заниматься. ППКС.
Ежегодно сотрудники заполняют анкету, оценивая каждого коллегу на основании всего двух пунктов:
— «Вклад этого сотрудника в общее дело (гораздо) больше или (гораздо) меньше,
чем мой» (шкала от –3 до +3);
— «Этот сотрудник способен оценить меня» (шкала от 1 до 5).
Ответы обрабатываются по простому алгоритму, коллег делят на несколько зар-
платных сегментов
 Все равны, но некоторые равнее...
Вы, как и ваши коллеги, пишете заявление о повышении зарплаты, которое считаете справедливым, и объясняете почему. Затем вы показываете заявление нескольким коллегам из выбранного ранее комитета по заработной плате. Комитет имеет право только советовать. Вы можете принять замечания комитета к сведению или сохранить повышение
зарплаты, которое сами установили.
А как же Даннинг-Крюгер?


среда, 25 марта 2015 г.

Ответов на вопросы пост

Ответ на вопросы, которые мне задают при встрече знакомые и не очень люди, рано или поздно, так или иначе.
Почему ты уволился из яндекса?
Обстоятельства сложились так, что я больше не смог работать на проекте Яндекс Мастер - проекте, с командой которого я работал с самого начала.
И я не смог придумать, как я могу помочь другим проектам в других городах.
А еще я не хочу переезжать в Питер.
А не работать - это вообще плохо. Хуже только - плохо работать.
Куда ты ушел?
Сейчас я работаю в СКБ-Контуре, проект EDI
Работаю тестировщиком, надеюсь, что у меня получится нанести проекту пользу.
И я уже вижу, что у местных тестеров есть чему поучиться.
Ты дурак?
Ага

пятница, 10 октября 2014 г.

Есть вопросы

В последнее время неоднократно сталкивался с такой ситуацией и не до конца уверен, что я в ней прав..

Предусловия: к релизу есть несколько задач (исправленных багов), близится дедлайн, откат коммита из релизной ветки проблематичен и нежелателен.

В результате тестирования выясняется, что одн из фич- реализована, но не работает (или баг все еще воспроизводится).

Первый вариант действий: продолбать сроки релиза, но доделать фичу(исправить баг).
Второй вариант действий: катить релиз как есть, так как хуже не будет (тестирование кроме этого ничего не выявило). То есть фичи как нет, так и не появится (баг как воспроизводился, так и воспроизводится). Фактически - ничего не изменится в этом плане и ничего плохого не случится.

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


Мне интересно ваше мнение на эти счета. Вот только не надо нудить о приоритетах, срочности, критичности. Чаши весов (сроки и необходимость фичи) уравновешены и выбор зависит целиком от ваших религиозных взглядов и мировоззрения.

может быть у вас есть свои варианты - но с учетом условий.

пятница, 25 июля 2014 г.

Урок 3. Слайды 121-122

Меня вообще кто-нибудь читает? Живые люди?
В последнее время мне от политики становится грустно и немного тошнит.
Если тут есть кто живой - накидайте в комментарии блоги живых людей, которые пишут о жизни, о мире вокруг, о деле которому служат. А не делают репосты о новостях политики.

Пожалуйста. Я в ответ в ближайших выпусках тоже забацаю ссылки на настоящих, живых людей.


Поехали:

Слайд 121
Другие сравнения будут еще сложнее, так как нет четких ориентиров. Например, если в программе сложно сделать какую-либо вещь, это важно или нет?
Вам придется узнать, почему люди будут использовать ваш продукт. Если они купили его для нето, чтоб выполнять именно эту задачу, а ее в вашем продукте выполнить сложно, то мы получаем неконсистентность с ожиданиями пользователей и сделаем их раздраженными.
Возможно, тут так же есть неконсистентность с мнением компании о целях продукта- мнение о том, почему люди хотят работать с продуктом.

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

вторник, 15 апреля 2014 г.

Доброе утро

Do you want to play a game?
Например так, Екатеринбург, где это?

понедельник, 17 февраля 2014 г.

Есть вопросы

Сколько писем в день вы не читаете?

Уточню: сразу исключим спам из подсчета.
Но - будем учитывать всю рабочую переписку и все уведомления - от жежешечки, твиттера, JIRA, redmine и прочее.

Не читаете переформулируем так: не ведут к каким-либо действиям кроме "пометить как прочитанное".

среда, 12 февраля 2014 г.

Странное

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

В общении: переписке или диалоге отвечать только на те мысли или вопросы, на которые им отвечать приятно или выгодно. Ну то есть примерно на половину. Иногда приходится раза по три доспрашивать.
По большей части - в рамках работы, полезной какой-то деятельности, то есть не праздные беседы или там развлечения.
И как-то все это у них элегантно выходит. Как-то непривычно игнорировать не человека вообще, а каждый третий вопрос. И случай-то не единичный, хм.

Посему три вопроса.
Первая: Это у людей такой особый, гуманитарный склад ума, когда больше одной мысли в памяти не помещается?
Вторая: А может время этих людей настолько ценно и они задумываются только о важном?
Третья: Кто меня знает, я сам так не делаю? А то запросто, могу ведь и не замечать (мой любимый способ - не отвечать на утверждения не считается, хех).

пятница, 30 августа 2013 г.

Есть вопросы

А за чем бы вы пошли по дороге из желтого кирпича? Ясно, что не хватает, как всегда, мозгов, как у Страшилы.

А чего - хочется? Мне бы сердце..

пятница, 26 июля 2013 г.

Вопрос

Посоветуйте twitter клиент под андроид, кроме официального.

вторник, 14 мая 2013 г.

Вопрос

Если меня читают автотестеры, расскажите, чем так хорош method chaining?
Используете ли вы его в DSL, DAO, GUI методах?

понедельник, 25 марта 2013 г.

Lesson 256

Екб, коллеги. Кто-нибудь едет на апрельские SQA Days?

Слово Канеру

Создай портфолио

Очень удобно иметь набор исходных кодов, документов и других примеров, демонстрирующих ваши компетенции. Вы смогли бы использовать портфолио, чтоб показать компетентность такими способами, которыми этого не делают другие кандидаты. Однако, его создание — непростая задача.


В большинстве компаний ваша работа является собственностью компании и коммерческой тайной. Но вы могли бы написать несколько документов или часть кода, не относящихся к компании. Или создать что-либо, что перестанет попадать под действие тайны через несколько лет. Все это кандидаты для вашего портфолио. Некоторые руководители легко предоставят вам право использовать такие материалы, другие нет. Хорошей возможностью для получения права на использование материалов, которые вы создали в компании могут быть:
- Когда вы увольняетесь и ваш менеджер или представитель отдела кадров рассказывает вам о условиях увольнения. Если у вас на руках есть конкретные образцы работ, то они могут с радостью подписать документ, в котором говориться, что вы имеете право показать эти образцы будущим потенциальным работодателям с целью получения работы. Получите подпись, а не только словесное резрешение.
- Спустя шесть месяцев или год, если ваш руководитель все еще работает в компании и вы хорошо ладите.
- Материалы, которые уже использовали в качестве примеров на конференциях. Если было разрешено раскрыть секрет на конференции, то не нужно получать разрешение снова. Это уже больше не секрет.

Если вы разрабатывали По или писали статьи в ваше личное время, используя собственные ресурсы и если материалы, с которыми вы работали не связаны непосредственно с вашими задачами в компании, то, вероятно, вы имеете право использовать то, что вы создали. Возможно, вы имеете право на плоды своих трудов в более широком диапазоне обстоятельств. Детали зависят от вашего контракта с работодателем и от законов, которые управляют этим договором.

пятница, 18 января 2013 г.

Епт =(

РазИгнорировать или разЫгнорировать?
Эта ссылка права?
http://www.gramota.ru/class/coach/tbgramota/45_66

четверг, 17 января 2013 г.

Lesson 234

Где-то слышал, что хороший специалист может самую сложную свою работу объяснить понятными словами.

Склонен согласиться с этой мыслью.
Я сегодня искал причину падения тестов, оказалось, что у тестовой базы проблемы с русским. Collation задать надо было в скрипте развертывания.
Я вчера считал, сколько нам нужно будет железок для прогона тестов через полгода, если один тестировщик пишет n тестов в месяц, мы оптимизируемвремя прохождения тестов на x% в месяц, удаляем y тестов в месяц, параллелим в z потоков, по w потоков на железке, тест в среднем идет k секунд, накладные на дополнительное распараллеливание j секунд, это все умножить на h веток из расчета по одной ветке на f программистов, которых у нас d человек сейчас, а через полгода будет +s штук. И учесть, что сейчас q тестировщиков пишут тесты, а через полгода им будут помогать r человек писать кейсы, что увеличит скорость написания тестов на t%. Ну и накладные u% времени на поддержку, которые зависят от количества тестов и их качества. Все ж понятно, нам надо в два-три раза больше железок, чем сейчас.

Но иногда я слышу такой ответ: "Думаю, руковожу, слежу и контролирую".

Буллшит! Если не полное симбурде.

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

Переписывался с клиентами на тему их потаенных желаний, оформлял бумажки с отпусками, проводил собеседование, создавал задачки в jira, отпинывался от стремных задач, делал ревью вашего кода, считал статистику, медитировал на прогресс сборок в jenkins, сидел на пяти совещаниях, три часа уговаривал Петю не увольняться - это я понимаю. По разному отношусь, но понимаю.

«Руководил, думал, следил за выполнением, контролировал, управлял» - буллшит.

Но у вас наверняка есть свои версии на все эти счета?(c)

Слово Канеру

Планируйте в терминах задачи, которую вы делаете и навыков, необходимых для ее выполнения.

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

Есть вопросы

Скилл бьет класс или наоборот?
Ваше мнение важно для меня.
Я о ИРЛ.

понедельник, 14 января 2013 г.

Lesson 231

Альбом: randompics4lj


В связи со слухами о ЖЖкапце хочу продублировать свой бложик на альтернативной платформе. А может и переехать.

Варианты:

wordpress
blogger
tumblr

Требования:
1. Импорт из жж. Здесь в выдаче гугла по 700к ссылок для wordpress и blogger, 300к для tumblr. Вывод очевиден.
2. Поддержка опенайди и прочей авторизации. Везде есть.
3. Поддержка rss. Везде есть.
4. Простота ведения. Хм, я думаю, что осилю.
5. Клиент под андроид. Нашел все три, какой из них удобней?
6. Возможность формировать ленты из других блогов, списки интересных блогов итпх.
7. Очень не хочу терять френдов, я вас всех очень ценю и читаю. Несколько лет собирал.
Наверняка вам есть что выразить по этому поводу. От жж-юзеров жду как минимум не-уходи-постой.


Слово Канеру

Ваши решения о найме — самые важные

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

Сделайте все возможное, чтоб нанять хороших людей.

вторник, 11 декабря 2012 г.

Lesson 222

Давайте представим...
Тебе, да-да, именно тебе сказали, что в соседней стране соседней компании соседнем отделе соседней комнате работают лучше тебя.
- Кто? Они? Да они же нихрена не умеют.
- Умеют... смотри, багов пропущено меньше, времени потрачено всего ничего...
- Да у них таски никакие!
- Вообще-то ваши же таски брали, помогали вам, вот...

Короче - работают лучше тебя. Вон те. Ваша реакция? Ваши версии? Первые мысли. А?



Слово Канеру

Знакомьте новых тестировщиков с продуктом через позитивное тестирование

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

Цель этого заключается в том, чтоб помочь составить представление о продукте. Исходя из него он будет более информированным и эффективным критиком, когда он будет искать сбои.

четверг, 22 ноября 2012 г.

Lesson 209

Тестеры, есть вопрос.
Вам дали постановку, небольшая юзерстори/фича, 1-3 часа тестирования, 2 экрана постановки.



Ваше мнение очень важно для меня.

Слово Канеру

В полезном отчете по релизу перечислены 10 худших проблем, которые смогут найти критики.

Представьте, что вы выпускаете ПО для продажи. Перечислите 10 наихудших вещей, которые смогут сказать о нем рецензенты. Если проблемы достаточно серьезны, маркетологи компании (или другие сотрудники) могут задержать релиз. Это будет наиболее полезная оценка качества, которую вы можете предоставить (Заметим, что такой подход позволяет говорить с позиции критика ПО, не пытающегося дать объективную картину качества).

среда, 19 сентября 2012 г.

Lesson 174

Друзья, а какие вы используете андроид приложения?

Альбом: home


Для друзей, использующих приложения с иных платформ, хотелось бы процитировать хабр:

Dv0rsky: Месяц назад перешел на НТС после нескольких лет использования айфонов
qde5n1k: и как впечатление?
Tematika: … стал меньше заглядываться на мужские задницы

Слово Канеру

Используйте smoke тесты для оценки билда.

Smoke-тесты (или проверка корректности или приемочный тест) представляют собой набор тестов, целью которых является проверка базовой функциональности билда. Если билд проваливает тест, то он объявляется нестабильным, не подлежащим тестированию.

Обычно, когда новый билд попадает в тестирование, один из тестировщиков запускает smoke-тест (который может быть автоматизированным, проводиться вручную или комбинацией этих способов). Другие тестировщики игнорируют билд, пока он не пройдет smoke-тестирование. Он включает набор стандартных, базовых тестов и несколько временных (тесты, которые будут существовать несколько сборок), сосредоточенных на какой-то ошибке или фиче, представляющей интерес в этой сборке.

Процесс smoke-тестирования публичен. В приличных компаниях программисты получают копии всех документов, описывающих тесты и код, запускающий smoke-тесты. В других компаниях, программисты запускают smoke-тесты автоматически, как часть процесса сборки. Все понимают, что если ПО не проходит тест, оно не попадает в тестирование. Этот процесс без сюрпризов. В этих условиях smoke-тест рассматривается как техническая, а не политическая задача, и большинство людей в проекте (включая большинство или всех менеджеров) считают ее разумной.

вторник, 21 августа 2012 г.

Есть вопросы

Хорошая задачка от Александра Селяева

Бывает ли автоматизированное регрессионное функциональное тестирование черного ящика?

пятница, 17 августа 2012 г.

Lesson 151

Диалоги. О рыбалке.

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

Альбом: randompics4lj


«А вот в компании %местный_бренд%» зарплаты на десять тыщ больше.
Так они и вьебывают яростно и с энтузиазмом. Творят всякое. Время, что характерно, находят.

Я к чему это. Эффективные способы научиться — это учить и запилить реальный проект. Я в последнее время сильно дофига всего не умею и не понимаю. И у меня есть проектик за тестирование. Екб, нау может кому интересно?

Слово Канеру

Работай на доверие программистов

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

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

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