Как-то все это похоже на "Выучи Х и станешь Y". Хотя все знают, что эта формула по сути вранье. Учиться нужно постоянно, и в лучшем случае она должна выглядеть как "Для работы в качестве Y может быть полезным знать X" И тогда оказывается, что полезным может быть все.
Я например в молодости читал Лебедева по дизайну, и могу аргументированно доносить нефункциональные баги в пользовательском интерфейсе до "стейкхолдеров". И это невероятно полезный навык, понимать азы правильного устройства интерфейсов. И что еще важнее как аргументировать убедительно, но не обидно.
Или например, как насчет навыка письма и общения. Я должен сказать, что комментирование на хабре и других платформах здорово прокачало мои коммуникационные навыки за пару лет. Потому что для этого сперва нужно иметь мнение, а потом постараться выразить его так чтобы никому не навредить, даже если это критика. А тестировщик он всегда критик (в хорошем смысле этого слова). Не критикан, а критик. Для этого нужно развивать критическое мышление. Задаваться вопросами. А почему так. Не принимать все на веру. Спрашивать себя "а что если".
А что касается практики - пожалуйста, бесплатная практика:
Берем любую опенсорсную софтину.
Разбираемся в ее устройстве.
Находим в ней ошибки.
Открываем багтрекер проекта.
Регистрируемся.
Пишем багрепорт с учетом гайдлайнов проекта.
Ждем когда баг категоризируют, распределят и начнут над ним работу
Отвечаем на дополнительные вопросы разработчика. Помогаем ему тестировать дополнительные сценарии, чтобы точнее выявить условия проявления нежелательного поведения.
Ждем когда баг починят и тестируем новый релиз
Profit Опыт.
Эти багрепорты публичные и на них можно легко сослаться, нет NDA. Создайте свой репозиторий на гитхабе и храните там ссылки на свои багрепорты. Понадобиться сослаться в резюме - удобно, одной ссылкой. Будет еще и подтверждение минимального опыта работы с Git. Ну и не будем забывать, что работа над опенсорсом у всех в почете.
Домашнее задание:
Найти публичные багтрекеры десяти опенсорсных проектов в интернетax.
Полезное упражнение: воспроизведите чужой баг Коли вы уже нашли публичные багтрекеры - покопайтесь в них, найдите открытый баг подходящий для воспроизведения в вашем окружении, воспроизведите его. Упражниение полезно в первую очередь для того, чтобы понять недостатки в багрепортах и самому стараться в будущем этих недочетов избегать.
Еще одноупражнение: Возьмите любое известное вам приложение, например на мобильном телефоне. Проследите за тем как именно вы пользуетесь определенной функцией. Опишите эту функцию в виде тестового сценария. Возьмите другое устройство, и проверьте работает ли этот сценарий на нем.
P.S.: Лайфхак, если не знаешь что можно тестировать в приложении. Я недавно пробовал ChatGPT и попросил его подсказать тестовые сценарии для <тип приложения>. И получил список вполне годных идей.
О, точно. Я просто привык контекстное меню на вкладке открывать, а в хроме нужно на свободном месте панели открывать. Спасибо, век живи.. A, и хром начинает раньше ужимать вкладки оставляя всегда свободный кусочек на панели чтобы можно было открыть контекстное меню. Что конечно не так удобно чем когда можно открыть контекстное меню на любой вкладке.
Насчет капс-лока скажу, что если ты играешь в какую-нибудь стрелялку, и из-за мизинца на шифте не видно огонек на капс-локе, то лучше когда он вынесен. Так что рекомендации рекомендациями, но бывает по-разному.
--
Самые востребованные кнопки - крупные,
реже используемые - размером меньше
На иллюстрации две кнопки умножить :) Так и хотелось добавить "А наиважнейшие кнопки - продублированы на всякий случай"
--
Про отмену действия - меня всегда удивляло что в хроме такую удобную функцию как восстановить последнуюю закрытую вкладку убрали куда-то в меню журнала. Когда в огнелисе она в контекстном меню на линейке закладок. Странно, казалось бы гугл должен быть примером, но часто у них ничем хорошим не выделяющееся юзабилити (как минимум в браузере) и они как будто совсем не стремятся улучшать что-то в этом направлении. Они в основном рендеринг улучшают, поддержку стандартов, инструменты для разработчика, а сам пользовательский опыт с браузером у них на заднем плане.
Хотя, строго по определению генеративные нейронные сети проявляют в результатах работы эмерджентность. Нейроны в комплексе проявляют то чего небыло в каждом отдельном нейроне.
Значит эмерджентность сама по себе не интересная характеристика. Для рисующей нейросети уже было бы чудом если на запрос идеальный черный квадрат, она нарисовала попиксельно абсолютно черный квадрат. Но рисующая нейросеть не в состоянии этого сделать. Проще монете встать на ребро. Она нарисует любые вариации черного квадрата. А человек запросто это сделает.
Вы считаете что если на вопрос "как дела" нейронка неожиданно отвечает, предположим, стихами хайку в тему погоды и мировых новостей, то это эмерджентность? Нет, это все еще машина синтезирующая текст, на основе известных ей других текстов. Нейронка натасканая на синтез текста, не сможет сделать ничего кроме этого.
Удивительно другое. Что наша письменная речь, видимо, настолько "примитивна", что машина может используя множетство всех слов и предложений в качестве примеров, методом подобия/подражания создавать тексты, которые мы воспринимаем и оцениваем как уникальные.
Я думаю увеличивая количество параметров, мы получим машину еще лучше синтезирующую ответы на базе обработанногого массива текстов. Т.е. ее ответы станут еще более похожими на человеческие. Дело в том что это усиление по одному вектору - контекстному синтезу текста. От этого машина не перестанет быть машиной.
Главная проблема теста Тьюринга на мой взгляд в том, что этот тест, полностью упускает из виду тот факт, что человека человеком делают не только ответы на вопросы.
Поэтому если уж идти по пути аргументации, что мол человек в конце концов тоже просто очень сложный биоробот, то современному искусственному интеллекту все равно невероятно далеко до человека. И я предполагаю, что даже если мы соединим несколько специализированных искуственных интеллектов (приблизительно ориентируясь на количество органов чувств) в один, снабдим это все коррдинирующим ИИ, мы на выходе получим удивительное искуственное существо которое будет неверятно похоже во многих аспектах на человека, оно сможет выражать эмоции не только вербально но и невербально, будет проявлять эмпатию и так далее. Снабдив такую машину набором целевых функций мы сможем получить совершенно самостоятельный новый вид роботизированных человекоподобных существ, которых невозможно отличить от человека.
Но вот что меня настораживает. Наше понимание человека как биоробота, (по образу которого собственно и строится человекоподобная машина) возможно имеет существенный, нами пока не октрытый недостаток. Т.е. когда мы создадим ИИ полностью удовлетворяющую нашей модели биоробота, мы вдруг выясним, что человек больше чем биоробот. Потому что этим новым идеальным роботам будет "чего-то" нехватать. Хотя в любой непосредственной области жизнедеятельности они будут превосходить человека в способностях.
Я думаю что точно сложно, так это именно найти конечное множество целевых функций, чтобы машина обладала полноценной собственной волей и целеполаганием. Или нужно научить машину синтезировать новые целевые функции из ей известных, извлекать их из собственного окружения...?
Да я думаю мы упремся в то, что чего-то такого не понимаем о человеке, без чего создание идеальной человекоподобного робота окажется невозможным.
Что касается программирования с помощью AI, меня не покидает смутное ощущение, что тут появляется лишнее звено. Это как использовать лазерный меч, чтобы точить им топор для рубки деревьев. Как-то тупо. (Прошу прощения за каламбур). Надо чтобы ИИ переводила человеческий язык сразу в машинный код. Только вот это будет невозможно, потому что принцип работы этого ИИ - синтез текста из огромнейшей базы примеров использования слов. Соответственно, такой ИИ ничего не "понимает" из того, что "говорит".
Могу порекомендовать вот это интервью с Майком Паундом https://www.youtube.com/watch?v=PH9RQ6Yx75c У кого совсем нет времени, достаточно посмотреть кусок где он рассказывает про LaMDA. И когда ты ясно видишь суть того чем эта машина является, она перестает быть такой загадочной. И ее ответы уже не восхищают. Это простой синтез текста. Смыслы определяет человек. Машина этого сделать не может. Да, она может синтезировать с невероятной вариативностью. Но интерпретировать результаты синтеза будет человек. Человек дает оценочные суждения. Человек придумал язык, и вкладывает в него смыслы. Человек общается на языке, а машина просто составляет фразы из того что где-то прочитала, ничего при этом не понимая. И становится предельно ясно что интеллектом такая машина не обладает.
Я очень надеюсь, что исследования в области ИИ помогут человеку понять свою собственную природу.
В оригинале 20 инструментов собрано, но из них тут представлено только 9? Впрочем, неважно, все равно я верю только в CucumberStudio от SmartBear. Кстати, у них можно с github учеткой войти и попробовать.
Так дело в том что если компания хочет улучшаться то она может это делать. Японские практики управления этому хороший пример - Андон, Гемба, Кайзен. Но видимо многие компании не хотят улучшаться. Почему? Потому что в пирамиде управления каждый в принципе заботится только о себе а не о компании. Гнилые люди - гнилая организация. А в гнилой организации в перспективе остаются только гнилые люди. Нормальные уходят. Я сам был свидетелем того как наша маленькая но уважаемая айтишная контора после покупки крупным айти сервис провайдером, скатилась в полное УГ за 4 года. Все выдающиеся личности оттуда поуходили. Остались те кто не готов к переменам. И балласт. Маркетинг работает хорошо, а за фасадом - полное УГ. Мне кажется люди которые варятся в УГ перестают в какой-то момент относиться к этому критически, и все. А без этого не может быть изменений. И получается люди ходят вокруг куч этого УГ, в упор их не видят, но говорят о том "какое небо голубое" и какая еда в столовой вкусная. Просто смещается фокус. Это такая адаптация мозга, чтобы ему не было больно, он начинает фильтровать.
Я думал будет что-то типа "резонансная частота трубы меняется при снижении температуры". Безо всяких терморезисторов, чисто на звуке. Вот это было бы вообще крышесносно.
Потому что я хочу создать условия, при которых система увидит свою неэффективность и исправится.
Идея понятна и весьма благородна. И подход такой я и сам приветствую, через смену условий менять поведение. Но вот только нужно быть увереным, что смена условий повлияет именно на интересующий нас субъект. Боюсь, повышая нагрузку на техподдержку повышается только нагрузка на техподдержку. И возможно в этом и основная проблема, что цепь коммуникации разорвана и техподдержка вообще никак не влияет на владельцев или менеджмент. А по итогу, например, менеджер колл-центра распечатает статистику и даст взбучку тем кто портит KPI.
Я перешел на место с 35 часовой неделей. За три месяца (т.е. ~12 недель) набралось 30 часов переработки. т.е. это 3 часа переработки в неделю в среднем. На работе с 40 часовой неделей мне иногда было трудно закрывать часы. Потому что твоя продуктивная фаза сошла на нет а рабочее время еще осталось. Ну и когда работаешь один ( а раньше я работал один ) у тебя все время продуктивное, ты сам себе менеджер. Когда работаешь в команде - 60-80% времени уходит на повторяющиеся и запланированые созвоны. Т.е. на работу остается 8-16 часов в неделю в лучшем случае. И это начинат давить.
В опыте русской компании по ссылке из статьи, интересно, что человек не получал выходной, а получал рабочий день в режиме "не беспокоить". Это мне кажется самый важный момент. Это именно то, чего мне интуитивно нехватает, когда дни больше чем на половину заполнены совещаниями. Просто время обработать весь поток информации на едине с собой. Или проработать что-то без прерываний.
P.S.: Вообще ,прочитав, что во время эскперимента наблюдалось повышение доходов компании подумал что тут какое-то нарушение причинно-следственной связи. Заглянул в полный отчет а там написано: "The first metric is revenue, perhaps the most global measure of performance". Ясно, понятно. Xотелось бы разяснений со стороны ученых каким образом производительность связана с доходами. Хотя опосредованную связь я не отрицаю.
Так вот, они посчитали 36 процентов прироста дохода по сравнению со средними значениями в течении шести месяцев за 2021 год. И 8 процентов в среднем за период проведения эксперимента. Так вот нигде нет подтверждения тому что этот прирост произошел по причине эксперимента, и не произошел бы иначе. [sarcasm] И сколько времени им понадобилось, чтобы выбрать из всех участников эксперимента тех у кого случился прирост [/sarcasm]. Тут явный туман и нарушение причинности. Но всем пофиг.
Стараешься не вникать в счет времени пока тебя это не коснется в работе. Но тогда уже как правило поздно (прошу прощения за каламбур). To же самое с представлением чисел с плавающей точкой в компьютере. Ты знаешь, что там есть свои особенности, но не вникаешь в них пока тебя это не коснется в работе. Спасибо за материал!
Насколько бы тщательным тестирование не было, нельзя учесть все возможные сценарии и предвидеть все возможные ошибки.
Я бы уточнил, что именно физически полное тестирование невозможно. Учесть и предвидеть можно. Невозможно именно все это протестировать за сколько нибудь приемлемый временной отрезок.
Вообще мне очень близка идея "диздока", и мне не понятно почему в области разработки пользовательских приложений не используют такой же подход. Там как правило с документацией проекта все плохо. Она делается часто для галочки, а не для того чтобы внести ясность среди участников о назначении приложения и роли каждой отдельной функции в рабочих сценариях пользователя. Даже если мы имеем "юзер-стори" то написаны они часто так что необходимой ясности и связности в них нет. Впечатление, что в разработке приложений нет никакой конечной цели, общего видения и дизайна в широком смысле, а работа делается там где возникла сиюминутная необходимость.
А по CDP нельзя спросить у браузера, типа, он окончательно успокоился, или еще что-то думает и пережевывает? Я не знаю возможностей CDP, поэтому и спрашиваю.
"Пока я тут считаю голоса, что ты сделаешь, а?"
Thomas Nast (1871)
Карикатура посвященная периоду беспрецендентной политической коррупции в Нью Йорке во второй половине 19 века, под руководством Уильяма Твида.
Поэтому совершенно неважно насколько надежен процесс сбора голосов, важно чтобы их подсчет был прозрачным, и защищенным от манипуляции. Что нибудь типа голосования с помощью электронной подписи. Голос сразу учитывается и выводится публично в общую статистику, никакого процесса "подсчета" не нужно. Чтобы "вбросить" голоса в такую систему придется создавать дополнительные ключи для несуществующих граждан.
Если конечно все последовательно перевести на такую электронную систему учета, то вместе с прозрачностью выборов, люди начнут жаловаться что за ними следят на каждом шагу, потому что любую гражданскую операцию придется подтверждать ключом, смену места жительства, смену паспортных данных и.т.п. И потом как быть с утеряной картой. Что делать в случае смерти. Есть шанс что карты/ключи не будут надлежащим образом уничтожаться и будет опять пул ключей который можно будет использовать для манипуляции. Но если использование голоса/ключа возможно только по месту жительства, и соответственно машина будет принимать только ключи со своего избирательного участка, то чтобы добвить голоса "мертвых душ", придется эти лишние карты распределять по всей стране, это уже неудобно как минимум. Ну и конечно машина регистрирует время отдачи голоса, и если данные прозрачны и открыты то последовательный быстрый ввод голосов можно засечь статистически в данных. Короче, наверняка можно это сделать если сильно захотеть. Как минимум систему более прозрачную чем сейчас.
Интересно еще, если граждане сами создадут такую открытую децентрализованую электронную систему, можно заставить государство признать ее официально? Вот это была бы демократия.
В Вашем примере подразумевается, что результаты работы разработчиков взаимосвязаны. Это работает, потому что спринт наполнен взаимосвязаными задачами, которые вместе добавляют новую функцию в приложение. Тогда работа может быть поделена например на фронт, апи и бекенд и естественным образом этим трем участникам нужно синхронизироваться. То с чем доводилось сталкиваться мне, это когда в спринт берутся несколько функций плюс багов между собой не связаных, а просто выделеных по приоритету и уместившихся по сумме строипоинтов в емкость команды. Например: баг с подвисанием приложения, баг когда прогресс бар не отображается, возможность маркировки и комментирования данных в сводной таблице, функцию восстановления последнего открытого проекта после перезапуска приложения. Т.е. достаточно разные области приложения, практически никак друг с другом не связаные.
Может такой подход к планированию спринта уже есть ошибка?
Как-то все это похоже на "Выучи Х и станешь Y". Хотя все знают, что эта формула по сути вранье. Учиться нужно постоянно, и в лучшем случае она должна выглядеть как "Для работы в качестве Y может быть полезным знать X" И тогда оказывается, что полезным может быть все.
Я например в молодости читал Лебедева по дизайну, и могу аргументированно доносить нефункциональные баги в пользовательском интерфейсе до "стейкхолдеров". И это невероятно полезный навык, понимать азы правильного устройства интерфейсов. И что еще важнее как аргументировать убедительно, но не обидно.
Или например, как насчет навыка письма и общения. Я должен сказать, что комментирование на хабре и других платформах здорово прокачало мои коммуникационные навыки за пару лет. Потому что для этого сперва нужно иметь мнение, а потом постараться выразить его так чтобы никому не навредить, даже если это критика. А тестировщик он всегда критик (в хорошем смысле этого слова). Не критикан, а критик. Для этого нужно развивать критическое мышление. Задаваться вопросами. А почему так. Не принимать все на веру. Спрашивать себя "а что если".
А что касается практики - пожалуйста, бесплатная практика:
Берем любую опенсорсную софтину.
Разбираемся в ее устройстве.
Находим в ней ошибки.
Открываем багтрекер проекта.
Регистрируемся.
Пишем багрепорт с учетом гайдлайнов проекта.
Ждем когда баг категоризируют, распределят и начнут над ним работу
Отвечаем на дополнительные вопросы разработчика. Помогаем ему тестировать дополнительные сценарии, чтобы точнее выявить условия проявления нежелательного поведения.
Ждем когда баг починят и тестируем новый релиз
ProfitОпыт.Эти багрепорты публичные и на них можно легко сослаться, нет NDA. Создайте свой репозиторий на гитхабе и храните там ссылки на свои багрепорты. Понадобиться сослаться в резюме - удобно, одной ссылкой. Будет еще и подтверждение минимального опыта работы с Git. Ну и не будем забывать, что работа над опенсорсом у всех в почете.
Домашнее задание:
Найти публичные багтрекеры десяти опенсорсных проектов в интернетax.
Полезное упражнение: воспроизведите чужой баг
Коли вы уже нашли публичные багтрекеры - покопайтесь в них, найдите открытый баг подходящий для воспроизведения в вашем окружении, воспроизведите его. Упражниение полезно в первую очередь для того, чтобы понять недостатки в багрепортах и самому стараться в будущем этих недочетов избегать.
Еще одно упражнение: Возьмите любое известное вам приложение, например на мобильном телефоне. Проследите за тем как именно вы пользуетесь определенной функцией. Опишите эту функцию в виде тестового сценария. Возьмите другое устройство, и проверьте работает ли этот сценарий на нем.
P.S.:
Лайфхак, если не знаешь что можно тестировать в приложении. Я недавно пробовал ChatGPT и попросил его подсказать тестовые сценарии для <тип приложения>. И получил список вполне годных идей.
В том то и дело, что ChatGPT-подобные машины умеют по контексту отличать значения фраз. А если надо она еще и переспросить или уточнитъ может.
О, точно. Я просто привык контекстное меню на вкладке открывать, а в хроме нужно на свободном месте панели открывать. Спасибо, век живи..
A, и хром начинает раньше ужимать вкладки оставляя всегда свободный кусочек на панели чтобы можно было открыть контекстное меню. Что конечно не так удобно чем когда можно открыть контекстное меню на любой вкладке.
Насчет капс-лока скажу, что если ты играешь в какую-нибудь стрелялку, и из-за мизинца на шифте не видно огонек на капс-локе, то лучше когда он вынесен. Так что рекомендации рекомендациями, но бывает по-разному.
--
На иллюстрации две кнопки умножить :) Так и хотелось добавить "А наиважнейшие кнопки - продублированы на всякий случай"
--
Про отмену действия - меня всегда удивляло что в хроме такую удобную функцию как восстановить последнуюю закрытую вкладку убрали куда-то в меню журнала. Когда в огнелисе она в контекстном меню на линейке закладок. Странно, казалось бы гугл должен быть примером, но часто у них ничем хорошим не выделяющееся юзабилити (как минимум в браузере) и они как будто совсем не стремятся улучшать что-то в этом направлении. Они в основном рендеринг улучшают, поддержку стандартов, инструменты для разработчика, а сам пользовательский опыт с браузером у них на заднем плане.
Хотя, строго по определению генеративные нейронные сети проявляют в результатах работы эмерджентность. Нейроны в комплексе проявляют то чего небыло в каждом отдельном нейроне.
Значит эмерджентность сама по себе не интересная характеристика.
Для рисующей нейросети уже было бы чудом если на запрос идеальный черный квадрат, она нарисовала попиксельно абсолютно черный квадрат. Но рисующая нейросеть не в состоянии этого сделать. Проще монете встать на ребро. Она нарисует любые вариации черного квадрата. А человек запросто это сделает.
Вы считаете что если на вопрос "как дела" нейронка неожиданно отвечает, предположим, стихами хайку в тему погоды и мировых новостей, то это эмерджентность? Нет, это все еще машина синтезирующая текст, на основе известных ей других текстов. Нейронка натасканая на синтез текста, не сможет сделать ничего кроме этого.
Удивительно другое. Что наша письменная речь, видимо, настолько "примитивна", что машина может используя множетство всех слов и предложений в качестве примеров, методом подобия/подражания создавать тексты, которые мы воспринимаем и оцениваем как уникальные.
Я думаю увеличивая количество параметров, мы получим машину еще лучше синтезирующую ответы на базе обработанногого массива текстов. Т.е. ее ответы станут еще более похожими на человеческие. Дело в том что это усиление по одному вектору - контекстному синтезу текста. От этого машина не перестанет быть машиной.
Главная проблема теста Тьюринга на мой взгляд в том, что этот тест, полностью упускает из виду тот факт, что человека человеком делают не только ответы на вопросы.
Поэтому если уж идти по пути аргументации, что мол человек в конце концов тоже просто очень сложный биоробот, то современному искусственному интеллекту все равно невероятно далеко до человека. И я предполагаю, что даже если мы соединим несколько специализированных искуственных интеллектов (приблизительно ориентируясь на количество органов чувств) в один, снабдим это все коррдинирующим ИИ, мы на выходе получим удивительное искуственное существо которое будет неверятно похоже во многих аспектах на человека, оно сможет выражать эмоции не только вербально но и невербально, будет проявлять эмпатию и так далее. Снабдив такую машину набором целевых функций мы сможем получить совершенно самостоятельный новый вид роботизированных человекоподобных существ, которых невозможно отличить от человека.
Но вот что меня настораживает. Наше понимание человека как биоробота, (по образу которого собственно и строится человекоподобная машина) возможно имеет существенный, нами пока не октрытый недостаток. Т.е. когда мы создадим ИИ полностью удовлетворяющую нашей модели биоробота, мы вдруг выясним, что человек больше чем биоробот. Потому что этим новым идеальным роботам будет "чего-то" нехватать. Хотя в любой непосредственной области жизнедеятельности они будут превосходить человека в способностях.
Я думаю что точно сложно, так это именно найти конечное множество целевых функций, чтобы машина обладала полноценной собственной волей и целеполаганием. Или нужно научить машину синтезировать новые целевые функции из ей известных, извлекать их из собственного окружения...?
Да я думаю мы упремся в то, что чего-то такого не понимаем о человеке, без чего создание идеальной человекоподобного робота окажется невозможным.
Что касается программирования с помощью AI, меня не покидает смутное ощущение, что тут появляется лишнее звено. Это как использовать лазерный меч, чтобы точить им топор для рубки деревьев. Как-то тупо. (Прошу прощения за каламбур).
Надо чтобы ИИ переводила человеческий язык сразу в машинный код. Только вот это будет невозможно, потому что принцип работы этого ИИ - синтез текста из огромнейшей базы примеров использования слов. Соответственно, такой ИИ ничего не "понимает" из того, что "говорит".
Могу порекомендовать вот это интервью с Майком Паундом
https://www.youtube.com/watch?v=PH9RQ6Yx75c
У кого совсем нет времени, достаточно посмотреть кусок где он рассказывает про LaMDA.
И когда ты ясно видишь суть того чем эта машина является, она перестает быть такой загадочной. И ее ответы уже не восхищают. Это простой синтез текста. Смыслы определяет человек. Машина этого сделать не может. Да, она может синтезировать с невероятной вариативностью. Но интерпретировать результаты синтеза будет человек. Человек дает оценочные суждения. Человек придумал язык, и вкладывает в него смыслы. Человек общается на языке, а машина просто составляет фразы из того что где-то прочитала, ничего при этом не понимая. И становится предельно ясно что интеллектом такая машина не обладает.
Я очень надеюсь, что исследования в области ИИ помогут человеку понять свою собственную природу.
В оригинале 20 инструментов собрано, но из них тут представлено только 9?
Впрочем, неважно, все равно я верю только в CucumberStudio от SmartBear. Кстати, у них можно с github учеткой войти и попробовать.
Так дело в том что если компания хочет улучшаться то она может это делать.
Японские практики управления этому хороший пример - Андон, Гемба, Кайзен.
Но видимо многие компании не хотят улучшаться. Почему? Потому что в пирамиде управления каждый в принципе заботится только о себе а не о компании. Гнилые люди - гнилая организация. А в гнилой организации в перспективе остаются только гнилые люди. Нормальные уходят.
Я сам был свидетелем того как наша маленькая но уважаемая айтишная контора после покупки крупным айти сервис провайдером, скатилась в полное УГ за 4 года. Все выдающиеся личности оттуда поуходили. Остались те кто не готов к переменам. И балласт. Маркетинг работает хорошо, а за фасадом - полное УГ. Мне кажется люди которые варятся в УГ перестают в какой-то момент относиться к этому критически, и все. А без этого не может быть изменений. И получается люди ходят вокруг куч этого УГ, в упор их не видят, но говорят о том "какое небо голубое" и какая еда в столовой вкусная. Просто смещается фокус. Это такая адаптация мозга, чтобы ему не было больно, он начинает фильтровать.
Я думал будет что-то типа "резонансная частота трубы меняется при снижении температуры". Безо всяких терморезисторов, чисто на звуке. Вот это было бы вообще крышесносно.
Идея понятна и весьма благородна. И подход такой я и сам приветствую, через смену условий менять поведение. Но вот только нужно быть увереным, что смена условий повлияет именно на интересующий нас субъект. Боюсь, повышая нагрузку на техподдержку повышается только нагрузка на техподдержку. И возможно в этом и основная проблема, что цепь коммуникации разорвана и техподдержка вообще никак не влияет на владельцев или менеджмент. А по итогу, например, менеджер колл-центра распечатает статистику и даст взбучку тем кто портит KPI.
Я перешел на место с 35 часовой неделей. За три месяца (т.е. ~12 недель) набралось 30 часов переработки. т.е. это 3 часа переработки в неделю в среднем.
На работе с 40 часовой неделей мне иногда было трудно закрывать часы. Потому что твоя продуктивная фаза сошла на нет а рабочее время еще осталось. Ну и когда работаешь один ( а раньше я работал один ) у тебя все время продуктивное, ты сам себе менеджер. Когда работаешь в команде - 60-80% времени уходит на повторяющиеся и запланированые созвоны. Т.е. на работу остается 8-16 часов в неделю в лучшем случае. И это начинат давить.
В опыте русской компании по ссылке из статьи, интересно, что человек не получал выходной, а получал рабочий день в режиме "не беспокоить". Это мне кажется самый важный момент. Это именно то, чего мне интуитивно нехватает, когда дни больше чем на половину заполнены совещаниями. Просто время обработать весь поток информации на едине с собой. Или проработать что-то без прерываний.
P.S.:
Вообще ,прочитав, что во время эскперимента наблюдалось повышение доходов компании подумал что тут какое-то нарушение причинно-следственной связи. Заглянул в полный отчет а там написано: "The first metric is revenue, perhaps the most global measure of performance". Ясно, понятно. Xотелось бы разяснений со стороны ученых каким образом производительность связана с доходами. Хотя опосредованную связь я не отрицаю.
Так вот, они посчитали 36 процентов прироста дохода по сравнению со средними значениями в течении шести месяцев за 2021 год. И 8 процентов в среднем за период проведения эксперимента. Так вот нигде нет подтверждения тому что этот прирост произошел по причине эксперимента, и не произошел бы иначе. [sarcasm] И сколько времени им понадобилось, чтобы выбрать из всех участников эксперимента тех у кого случился прирост [/sarcasm]. Тут явный туман и нарушение причинности. Но всем пофиг.
Ну и работа на нескольких работах тоже в странах с невысоким средним достатком тоже имеет место быть, соответственно среднее значение часов растет.
Стараешься не вникать в счет времени пока тебя это не коснется в работе. Но тогда уже как правило поздно (прошу прощения за каламбур).
To же самое с представлением чисел с плавающей точкой в компьютере. Ты знаешь, что там есть свои особенности, но не вникаешь в них пока тебя это не коснется в работе.
Спасибо за материал!
Я бы уточнил, что именно физически полное тестирование невозможно. Учесть и предвидеть можно. Невозможно именно все это протестировать за сколько нибудь приемлемый временной отрезок.
Вообще мне очень близка идея "диздока", и мне не понятно почему в области разработки пользовательских приложений не используют такой же подход. Там как правило с документацией проекта все плохо. Она делается часто для галочки, а не для того чтобы внести ясность среди участников о назначении приложения и роли каждой отдельной функции в рабочих сценариях пользователя. Даже если мы имеем "юзер-стори" то написаны они часто так что необходимой ясности и связности в них нет. Впечатление, что в разработке приложений нет никакой конечной цели, общего видения и дизайна в широком смысле, а работа делается там где возникла сиюминутная необходимость.
А по CDP нельзя спросить у браузера, типа, он окончательно успокоился, или еще что-то думает и пережевывает? Я не знаю возможностей CDP, поэтому и спрашиваю.
Карикатура посвященная периоду беспрецендентной политической коррупции в Нью Йорке во второй половине 19 века, под руководством Уильяма Твида.
Поэтому совершенно неважно насколько надежен процесс сбора голосов, важно чтобы их подсчет был прозрачным, и защищенным от манипуляции. Что нибудь типа голосования с помощью электронной подписи. Голос сразу учитывается и выводится публично в общую статистику, никакого процесса "подсчета" не нужно. Чтобы "вбросить" голоса в такую систему придется создавать дополнительные ключи для несуществующих граждан.
Если конечно все последовательно перевести на такую электронную систему учета, то вместе с прозрачностью выборов, люди начнут жаловаться что за ними следят на каждом шагу, потому что любую гражданскую операцию придется подтверждать ключом, смену места жительства, смену паспортных данных и.т.п. И потом как быть с утеряной картой. Что делать в случае смерти. Есть шанс что карты/ключи не будут надлежащим образом уничтожаться и будет опять пул ключей который можно будет использовать для манипуляции. Но если использование голоса/ключа возможно только по месту жительства, и соответственно машина будет принимать только ключи со своего избирательного участка, то чтобы добвить голоса "мертвых душ", придется эти лишние карты распределять по всей стране, это уже неудобно как минимум. Ну и конечно машина регистрирует время отдачи голоса, и если данные прозрачны и открыты то последовательный быстрый ввод голосов можно засечь статистически в данных. Короче, наверняка можно это сделать если сильно захотеть. Как минимум систему более прозрачную чем сейчас.
Интересно еще, если граждане сами создадут такую открытую децентрализованую электронную систему, можно заставить государство признать ее официально? Вот это была бы демократия.
В Вашем примере подразумевается, что результаты работы разработчиков взаимосвязаны.
Это работает, потому что спринт наполнен взаимосвязаными задачами, которые вместе добавляют новую функцию в приложение. Тогда работа может быть поделена например на фронт, апи и бекенд и естественным образом этим трем участникам нужно синхронизироваться.
То с чем доводилось сталкиваться мне, это когда в спринт берутся несколько функций плюс багов между собой не связаных, а просто выделеных по приоритету и уместившихся по сумме строипоинтов в емкость команды. Например: баг с подвисанием приложения, баг когда прогресс бар не отображается, возможность маркировки и комментирования данных в сводной таблице, функцию восстановления последнего открытого проекта после перезапуска приложения.
Т.е. достаточно разные области приложения, практически никак друг с другом не связаные.
Может такой подход к планированию спринта уже есть ошибка?