Под один проект "умного офиса" пробовали успешно малинку 4ю.
Но выяснилось, что есть готовый продукт с установкой на DIN-рейку: JetHome D1, у него уже на борту и ZigBee, и RS-482 (всякие вам модбас и прочее). Минус: оперативы в релизной версии 1 Гб и на каком-то этапе может не хватать оперативы для тяжёлого проекта на home assistant, но вроде готовят к выпуску версию на 2 гига.
Труконф из подборки как раз ориентирован больше на установку в корпоративной сети, посмотрите на оф сайте инфу, там всё чётко рассказано ) и возможностей значительно больше чем у джитси и прочих его клонах.
Хотя есть и облачный сервис, но он предоставляет несколько меньше фич
а всё почему? потому что он построен на бесплатном проекте Jitsi, только слегка забрендировали WebRCT-клиент. А Jitsi сам по себе урезан и мало что умеет
Очень интересно, спасибо, что поделились своим опытом. Как уже было написано в комментарии выше, возникает вопрос: если не секрет, почему базу знаний наполняет тех.поддержка у вас? Это у них не так много работы по тикетам и есть время писать тексты (а я знаю, что нормально написать текст, ещё и со скринами - не полчаса)? Или в целях экономии на штате технических писателей или другим причинам? Очень интересно ?
Со стороны своего же опыта развития базы знаний и документации в крупной компании, разрабатывающей решения для видеосвязи, изложу некоторые мысли. При этом у нас база знаний - отдельная сущность, а документация - отдельная. Документация по продуктам подробно описывает решения, их возможности, и ряд вопросов, поднятых в статье, покрываются грамотно написанной документацией (например, не надо делать статью о настройке программы, если об этом подробно написано в документации). А база знаний описывает задачи, какие-то модели применения продуктов в тех или иных ситуациях. И отдельно описывает детально в картинках "для новичков" какие-то важные основные моменты, которые клиенты могут полениться читать в документации (такое, к сожалению, есть, и надо подстраиваться). И наполнением базы знаний занимается выделенный отдел технических писателей.
И на практике (ранее я работал в другой компании разработчиком и сам описывал наше ПО) получается, что если нет тех.писателей, то тратят время на составление текстов тех.поддержка и/или разработчики, но делают это не так качественно и понятно, как мог бы писатель с айти-навыками. То есть КПД создания и описания продукта повышается при разделении задач.
Критерий № 1. Сотрудники прокачиваются, получают новую экспертизу, а время решения вопросов не сокращается.
Тут я совершенно согласен, и на самом деле как бы ни была организована работа с базой знаний, её цель для бизнеса - сократить затраты времени на решение повторяющихся запросов от клиентов. Уже как следствие будут частые заходы, прокачка сайта по SEO, любовь и доверие к компании, которая пишет понятные инструкции, и т.п.
Но при наличии выделенного отдела тех.писателей обе причины нивелируются, т.к. они делают свою работу, изучая и описывая продукт, и имеют для этого необходимые технические знания и умение общаться с разработчиками с одной стороны, и умение грамотно составлять тексты - с другой.
Запросы же на появление новых статей приходят исключительно от тех.поддержки или (в меньшей степени) возникают при выходе крупных обновлений продукта, когда надо описать интересный кейс применения свежей фичи. Тут важно взаимодействие и доверие в профессиональном плане между отделами.
Критерий №2. База знаний растет, количество клиентов увеличивается, а вопросы от них все те же.
Опять же, технический специалист (из тех.поддержки или разработчик) далеко не всегда является хорошим тех.писателем и может написать понятный и полезный связный текст. Указанная в данном критерии проблема грамотно решается выделенными писателями.
Критерий №3. Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют.
Тут речь уже больше про ознакомление с существующими статьями новых сотрудников компании. И тут есть несколько подходов. Например, составить список частых проблем со ссылками на соответствующие статьи. Но это время и как-то выглядит не продуктивно. Другой подход, полезный для клиентов и коллег - структурировать базу знаний по разделам и разнести по ним статьи. Это значительно ускорит поиск, и в большинстве случаев даже не понадобится искать что-то по сайту по ключевым словам.
Критерий №4. Только ограниченный круг людей пишет в базу знаний.
Тут сказать нечего - у нас это отдел тех.писателей, у нас есть необходимые скиллы и время для этого.
Критерий №5. Ни новые фичи, ни фикс багов не улучшают NPS (Net Promoter Score) продукта, либо улучшают незначительно.
В нашей компании практикуются вебинары с открытым обсуждением продуктов, чтобы получить от клиентов обратную связь и улучшить наши решения. Также у нас по всем каналам внешнего общения с ними (почта, обращения в тех.поддержку, Телеграм-канал) происходит сбор пожеланий, их анализ на адекватность и количество запросов, и внедрение в дальнейшем в продукт тех, которые являются действительно хорошими. Средства связи в 21 веке позволяют удобно собирать и обрабатывать такие запросы, и все довольны.
Критерий №6. Сотрудники либо топ-менеджмент не понимают, зачем нужна база знаний
Опять же, частный случай, если есть отдел тех.писателей, то компания уже ясно понимает, зачем он нужен ?
Им просто надо было сразу выводить средства после заработка ?
По сути это баг банка, почему должны теперь страдать клиенты - непонятно. Клиенты ничего не нарушали, не взламывали, не использовали кастомное ПО и т.п. Надеюсь, они отсудят свои средства, а банк впредь будет нанимать нормальных разрабов и тестеров, а не студентов за дошик.
Идеальная программа вообще не должна требовать чтения документации пользователем, для нормальной работы с ней.
Смотря в какой сфере программа. Если это простая рисовалка для детского развития на Андроид - это да, она максимально интуитивно понятная будет. Но если это серьёзный продукт (профессиональный графич.редактор, CRM, и т.п.), то лучше иметь документацию. Она понадобится минимум для двух случаев:
юзер (админ) таки что-то не может найти и ему придётся заглянуть в доку. И лучше, чтобы она была, чем он будет надоедать саппорту.
юзер (админ, что намного печальнее) что-то сломал/некорректно настроил/удалил какие-то привязки с другим ПО/и т.п., и теперь непонятно как починить без переустановки продукта. То есть ему надо увидеть таки рекомендуемый способ настройки нужных параметров и заново их конфигурировать.
Ну и да, даже у телеграма есть раздел с мануалами https://telegram.org/faq и явно не ради удовлетворения конкурса на поставку ПО гос.конторе ?
на основании все выше перечисленного ну и немного подсмотрел пришел к выводу что оптимальным это написание краткой инструкции в стиле "быстрого старта", но ссылками на инструкции составляющих частей, и расширенную инструкцию с подробным описанием моментов работы в проектом
На самом деле у нас тоже похожий подход в компании: мой отдел технических писателей составляет полную исчерпывающую документацию по всем разделам продукта, но есть короткие статьи с решениями определённых задач. Например, т.к. мы занимаемся видеосвязью, есть статья "Как позвонить пользователю", "Как организовать вебинар" и так далее.
Что касается пользовательской документации, то в идеале ее должны писать не разработчики.
Да, есть специальный отдел у крупных контор для этого - технические писатели. Они обладают скиллом писать понятно о сложном, и в то же время достаточными айти-скиллами, чтобы разобраться в продукте максимально глубоко. У любого крупного разработчика ПО есть обширные разделы инструкций, достаточно зайти на сайт Adobe, Яндекса, та кого угодно.
Когда пишет документацию разработчик - он тратит своё время не на свои обязанности. Это оправдано только если фирма маленькая, или это некий стартап, в общем есть момент экономии на кадрах. Или если самому разработчику это по приколу, и у него получается неплохо )
Про две страницы - зависит от продукта. По фотошопу условному не просто так сотни сайтов с инструкциями, та и свой хелп есть, т.к. продукт весьма сложен и без документации ты просто можешь не найти простой способ что-то сделать, и будешь заниматься "попиксельным рисованием".
Игра является просто калькой со старинной игры Mastermind https://en.wikipedia.org/wiki/Mastermind_(board_game)
Людям, знакомым с советскими головоломками, может быть известна под названием Логика. Например, у меня дома была такая, но куда-то затерялась, о ней тут уже писали: https://habr.com/ru/post/599669/
По сравнению с оригинальной задумкой стало больше элементов (с 8 до 26 для английск ого языка и 33 для русского). Но в качестве ограничения выступает то, что ответ - существующее слово из заранее известного словаря, а не случайная комбинация.
Я в детстве любил эту игру, и потестив, понял, что стратегия не поменялась по сути: сделав первое слово, где все буквы разные, я за 3 хода последовательно отдгадал.
Спасибо автору за разбор, но видно, что он не знал о Логике )
Кстати, отдельное спасибо за инфу о том, что словарь не так уж большой и собран вручную, не знал ?
Зависит от размера компании. Думаю, условный Эппл вполне себя видит через 5 лет )
У меня на практике про "кем себя видите?" спрашивали буквально пару раз может, сейчас этот вопрос уже выпилили из своего списка HRы. И спрашиали про 1 год - вполне нормальный горизонт планирования жизни любого уважающего себя работодателя, даже вчерашнего стартапа. Отвечал что-то стандартное типа "тим-лидом направления / начальником отдела".
Как минимум зайти на сайт и посмотреть с чем работает компания важно. Если идти "вслепую", то можно потратить своё время зря (время компании кандидату совершенно неинтересно, тут речь только про человека).
То есть при просмотре вакансии сложилось впечатление одно, а посмотрел профиль компании, может, отзывы о ней - и совсем другое. Или компания работает в сфере, неинтересной кандидату, не указав этого в вакансии (например, если человек не хочет работать в сфере торговли мясными изделиями, т.к. он вегетарианец). Пример утрирован, но это тоже влияет на образ компании в сознании кандидата.
Я не защищаю HR, они бывают сильно разные, особенно бесит, когда они совершенно не понимают ничего в вакансии и хлопают глазами, хотя бы образное начальное понимание должно быть, это сильно повышает в клазах кандидата позитивное отношение сразу с порога )
Если только из-за этого не взяли, то странная контора. Наоборот, раз их прорекламировали сарафанным радио, то значит, типа похвалили, радоваться должны. Я бы ещё уточнил на их месте: "И что о нас рассказали?, На какой позиции ваш знакомый работает/работал/или как узнал о нас сам?".
Понимать каналы распространения информации о компании всегда интересно.
Я о чём и говорю: можно даже если попсовый вопрос, не злиться, а проявить находчивость )
А новость о том, что в стрессовой ситуации человек не может или боится проявить смекалку/юмор/инициативу и делает то, что проще всего: врёт. Можно даже честно сказать: вопрос [текст вопроса] слишком типовый, вот вам типовый ответ, и дальше самый попсовый ответ )
Вопрос "кем вы себя видите?" помогает понять, что интересно из направлений деятельности потенциальному кандидату, что может помочь в предложении немного другой должности если он не стопроцентно проходит на собеседуемую. Но да, вопрос весьма попсовый и подбешивает.
По делу спрашивать должен уже технический специалист (будущий начальник и/или ментор).
Вопрос про компанию вообще, имхо, правильный, ведь если человек совершенно не поинтересовался, куда он идёт устраиваться, значит, в работе он тоже может быть часто таким же пофигистом. Хотя бы сайт открыть компании и посмотреть, чем занимается, и каковы отзывы в инете о ней если они есть, как минимум из здорового любопытства. А в мой отдел приходили общаться пару раз такие, которые даже сайт не открывали ?
В статье смешалось тёплое с мягким: заголовок о написании туториалов (aka мануалов, документаций, руководств), а текст - про нелюбовь автора к написанию их по ГОСТам.
По сути стиль написания инструкций зависит от сферы деательности компании и необходимости в этих самых ГОСТах. Ведь если нет задачи попасть в реестр Минсвязи и компания не работает с госконторами, то и нет необходимости придерживаться вообще каких-то ГОСТов. Пишите как нравится и чтобы было понятно клиентам. Можно даже с некоторой долей юмора, если позволяет корпоративная этика и специфика продукта?
Лично у меня по опыту приходилось писать и ближе к ГОСТам, и попроще - ближе к народу. Ну и опять же, лучше в случае крупных продуктов разделять инструкции к ним и статьи об их использовании в различных ситуациях с подробными примерами.
Любую свою публикацию я могу превратить в «туториал», переписав её согласно требованиям, и сократив раза в три таким образом.
А как статьи на Хабр писать - на самом же Хабре уже сломано миллионы копий и написаны десятки статей.
А тут нужна обратная связь от пользователей. В моём случае помогает общение с тех.поддержкой, и большая часть предложений по улучшению и дополнению как документации, так и статей базы знаний приходит именно от них. То есть появляются более-менее похожие тикеты, значит, тема либо не освещена, либо освещена не теми фразами и она не находится на вебах (поисковики свою работу сделали, проиндексировали, а фразы не те, что используются при поиске).
Благодаря такому двухстороннему общению появляются актуальные (за это отвечает мой отдел тех.писателей, следя постоянно за обновлением решений), так и полезные (о чём рапортует тех.поддержка) мануалы.
А статьи базы знаний у нас - это отдельная сущность, которая раскрывает некоторые кейсы по использованию решений. То есть в документации - что может продукт и какие предоставляет настройки с некоторыми простыми примерами, в статьях - уже более сложные примеры кейсов, для чего могут понадобиться те или иные настройки.
Спасибо за пояснения, логика в решении проблемы действительно очевидна, просто обидно может быть, что кому-то ушло в минус. Хоть я и недавно тут, но полезно. Жаль, что изначально не сделали такой очевидный подход. Ещё бы убрать разделение кармы и рейтинга и оставить один понятный коэффициент "адекватности и полезности автора".
Автору можно и в статью данное объяснение добавить, было бы полезно другим, дабы не листать комментарии и не искать.?
Изложу свои мысли по этому поводу, их самих на отдельную статью, но постараюсь кратко.
Со статьёй согласен, в полностью отечественной электронике всё примерно так и есть, не очень весело. А то, что работает – делается за рубежом.
Не вдаваясь в политику, приведу кое-какие соображения в дополнение к автору. Последний абзац выглядит как крик одинокого странника в пустыне, и оно и понятно ) Что же можно было бы сделать, и на что хорошее можно надеяться?
Всё-таки не так везде всё плохо. Как я уже упоминал, есть свои Эльбрусы, а ещё есть Байкалы. Да, делаются за рубежом на TSMC. Не надо ссориться ещё и с Тайванем, что тут сказать ))). Ещё есть контроллеры Овен, например, но там весь внутряк зарубежный, что подтверждает тезис статьи о том, что раз оно работает неплохо, то собрано не из местных чипов. К сожалению, пока так и получается...
В ПО дела обстоят таки веселее. И я не об «отечественных ОС», которые явно не состоят на 90% из накрученного на Linux-ядро криптографического и прочего одобренного ПО. Я о вполне неплохих и не менее, а то и более функциональных, чем забугорные аналоги, продуктах. Например, чем можно гордиться: любое ПО и поиск от Яндекса (тут без комментариев), комплекс решений для видеосвязи TrueConf (лидер в РФ и весьма известный за рубежом), офисный пакет Мой Офис (например, обзор посвежее и обзор тут же на хабре), бухгалтерское и прочее ПО от 1С, очень неплохой SCADA-пакет TraceMode (сам его юзал на прошлой работе, есть огрехи, но в общем хорош, у него живое коммьюнити, и проводят даже по нему олимпиады, и его изучают в ВУЗах), и много чего ещё. Для создания ПО нужны не такие бешенные сроки и заводы за миллиарды денег, как для чипов, так что тут попроще.
Как мне кажется, корни проблемы отставания в IT и электронике не в политике. Как уже писали в комментариях, в Японии есть свои компоненты, хоть и не делаются в таких кол-вах как китайские. Но они есть и наверняка качественные, а не как в статье. Опять же, Китай освоил штамповку своих процессоров как на полностью своей архитектуре, так и на купленной у AMD архитектуре Zen (и да, Хайгоны тоже штампуют на TSMC). Почему они могут? Дело начинается с самого детства в прямом смысле слова – с образования и науки. Подробно эта проблема рассмотрена в статье господина @3Dvideo «О русской науке…».
Пример из личного опыта
Насколько сейчас всё грустно в проблеме заинтересовать детей в массе что-то делать руками и узнавать новое, я недавно понял сам. У меня есть подруга – школьный учитель информатики. И она же по совместительству смотрит за парком техники в классах, обновляет ПО, чистит от шаловливых ручек детей и пр. В том числе пересобирает ПК и ноуты и иногда просит меня помочь. Я, как человек иногда занятой, как-то сказал ей: «Слушай, а что, из старшеклассников никому не интересно комп разобрать-собрать, помочь поковырять, узнать что-то новое о компонентной базе там и прочее?». На что последовал ответ: «Это у вас такие ещё были дети, 15 лет назад, сейчас они ленивы, инертны, торчат в мобилах и им неинтересно пыльные компы разбирать». То есть проблема идёт ещё со школы, что надо уже там уметь так поставить процесс, чтобы заинтересовать какую-то долю будущих айтишников. И начать с переработки программ, подходов к обучению, учебников и т.п.
Даже откинув политическую составляющую про защиту от внешнего мира и готовность к обрыву всех связей с поставщиками, иметь на своей территории производство важных компонентов тоже хорошо. Тут и возможность развивать своих специалистов (а то получается, что спецы в микроэлектронике и прочем только Китай с США), и побороться за какой-то рынок, может, что-то да изобрести. При должном отношении к качеству – уменьшить цепочки поставок, убрать зависимость от погоды и эпидемий, которые влияют на поставки через полпланеты. В общем, много плюсов даже в условиях мирного сосуществования. США вот озаботились этим вопросом, понятно, что с точки зрения предварительной защиты, но как я считаю, это полезно и в мирную эпоху. Вообще, к чему может привести сосредоточение производства чего-то важного в одном месте, можно увидеть на примере HDD и наводнения в Таиланде.
Кстати, "социальная леность" - это эффект Рингельмана, снижение индивидуальной производительности в группе, более 100 лет уже известное и в дальнейшем неоднократно доказанное и вне собственно мозгового штурма.
Под один проект "умного офиса" пробовали успешно малинку 4ю.
Но выяснилось, что есть готовый продукт с установкой на DIN-рейку: JetHome D1, у него уже на борту и ZigBee, и RS-482 (всякие вам модбас и прочее). Минус: оперативы в релизной версии 1 Гб и на каком-то этапе может не хватать оперативы для тяжёлого проекта на home assistant, но вроде готовят к выпуску версию на 2 гига.
Труконф из подборки как раз ориентирован больше на установку в корпоративной сети, посмотрите на оф сайте инфу, там всё чётко рассказано ) и возможностей значительно больше чем у джитси и прочих его клонах.
Хотя есть и облачный сервис, но он предоставляет несколько меньше фич
а всё почему? потому что он построен на бесплатном проекте Jitsi, только слегка забрендировали WebRCT-клиент. А Jitsi сам по себе урезан и мало что умеет
Очень интересно, спасибо, что поделились своим опытом. Как уже было написано в комментарии выше, возникает вопрос: если не секрет, почему базу знаний наполняет тех.поддержка у вас? Это у них не так много работы по тикетам и есть время писать тексты (а я знаю, что нормально написать текст, ещё и со скринами - не полчаса)? Или в целях экономии на штате технических писателей или другим причинам? Очень интересно ?
Со стороны своего же опыта развития базы знаний и документации в крупной компании, разрабатывающей решения для видеосвязи, изложу некоторые мысли. При этом у нас база знаний - отдельная сущность, а документация - отдельная. Документация по продуктам подробно описывает решения, их возможности, и ряд вопросов, поднятых в статье, покрываются грамотно написанной документацией (например, не надо делать статью о настройке программы, если об этом подробно написано в документации). А база знаний описывает задачи, какие-то модели применения продуктов в тех или иных ситуациях. И отдельно описывает детально в картинках "для новичков" какие-то важные основные моменты, которые клиенты могут полениться читать в документации (такое, к сожалению, есть, и надо подстраиваться). И наполнением базы знаний занимается выделенный отдел технических писателей.
И на практике (ранее я работал в другой компании разработчиком и сам описывал наше ПО) получается, что если нет тех.писателей, то тратят время на составление текстов тех.поддержка и/или разработчики, но делают это не так качественно и понятно, как мог бы писатель с айти-навыками. То есть КПД создания и описания продукта повышается при разделении задач.
Тут я совершенно согласен, и на самом деле как бы ни была организована работа с базой знаний, её цель для бизнеса - сократить затраты времени на решение повторяющихся запросов от клиентов. Уже как следствие будут частые заходы, прокачка сайта по SEO, любовь и доверие к компании, которая пишет понятные инструкции, и т.п.
Но при наличии выделенного отдела тех.писателей обе причины нивелируются, т.к. они делают свою работу, изучая и описывая продукт, и имеют для этого необходимые технические знания и умение общаться с разработчиками с одной стороны, и умение грамотно составлять тексты - с другой.
Запросы же на появление новых статей приходят исключительно от тех.поддержки или (в меньшей степени) возникают при выходе крупных обновлений продукта, когда надо описать интересный кейс применения свежей фичи. Тут важно взаимодействие и доверие в профессиональном плане между отделами.
Опять же, технический специалист (из тех.поддержки или разработчик) далеко не всегда является хорошим тех.писателем и может написать понятный и полезный связный текст. Указанная в данном критерии проблема грамотно решается выделенными писателями.
Тут речь уже больше про ознакомление с существующими статьями новых сотрудников компании. И тут есть несколько подходов. Например, составить список частых проблем со ссылками на соответствующие статьи. Но это время и как-то выглядит не продуктивно. Другой подход, полезный для клиентов и коллег - структурировать базу знаний по разделам и разнести по ним статьи. Это значительно ускорит поиск, и в большинстве случаев даже не понадобится искать что-то по сайту по ключевым словам.
Тут сказать нечего - у нас это отдел тех.писателей, у нас есть необходимые скиллы и время для этого.
В нашей компании практикуются вебинары с открытым обсуждением продуктов, чтобы получить от клиентов обратную связь и улучшить наши решения. Также у нас по всем каналам внешнего общения с ними (почта, обращения в тех.поддержку, Телеграм-канал) происходит сбор пожеланий, их анализ на адекватность и количество запросов, и внедрение в дальнейшем в продукт тех, которые являются действительно хорошими. Средства связи в 21 веке позволяют удобно собирать и обрабатывать такие запросы, и все довольны.
Опять же, частный случай, если есть отдел тех.писателей, то компания уже ясно понимает, зачем он нужен ?
Им просто надо было сразу выводить средства после заработка ?
По сути это баг банка, почему должны теперь страдать клиенты - непонятно. Клиенты ничего не нарушали, не взламывали, не использовали кастомное ПО и т.п. Надеюсь, они отсудят свои средства, а банк впредь будет нанимать нормальных разрабов и тестеров, а не студентов за дошик.
Смотря в какой сфере программа. Если это простая рисовалка для детского развития на Андроид - это да, она максимально интуитивно понятная будет. Но если это серьёзный продукт (профессиональный графич.редактор, CRM, и т.п.), то лучше иметь документацию. Она понадобится минимум для двух случаев:
юзер (админ) таки что-то не может найти и ему придётся заглянуть в доку. И лучше, чтобы она была, чем он будет надоедать саппорту.
юзер (админ, что намного печальнее) что-то сломал/некорректно настроил/удалил какие-то привязки с другим ПО/и т.п., и теперь непонятно как починить без переустановки продукта. То есть ему надо увидеть таки рекомендуемый способ настройки нужных параметров и заново их конфигурировать.
Ну и да, даже у телеграма есть раздел с мануалами https://telegram.org/faq и явно не ради удовлетворения конкурса на поставку ПО гос.конторе ?
На самом деле у нас тоже похожий подход в компании: мой отдел технических писателей составляет полную исчерпывающую документацию по всем разделам продукта, но есть короткие статьи с решениями определённых задач. Например, т.к. мы занимаемся видеосвязью, есть статья "Как позвонить пользователю", "Как организовать вебинар" и так далее.
Да, есть специальный отдел у крупных контор для этого - технические писатели. Они обладают скиллом писать понятно о сложном, и в то же время достаточными айти-скиллами, чтобы разобраться в продукте максимально глубоко. У любого крупного разработчика ПО есть обширные разделы инструкций, достаточно зайти на сайт Adobe, Яндекса, та кого угодно.
Когда пишет документацию разработчик - он тратит своё время не на свои обязанности. Это оправдано только если фирма маленькая, или это некий стартап, в общем есть момент экономии на кадрах. Или если самому разработчику это по приколу, и у него получается неплохо )
Про две страницы - зависит от продукта. По фотошопу условному не просто так сотни сайтов с инструкциями, та и свой хелп есть, т.к. продукт весьма сложен и без документации ты просто можешь не найти простой способ что-то сделать, и будешь заниматься "попиксельным рисованием".
Игра является просто калькой со старинной игры Mastermind https://en.wikipedia.org/wiki/Mastermind_(board_game)
Людям, знакомым с советскими головоломками, может быть известна под названием Логика. Например, у меня дома была такая, но куда-то затерялась, о ней тут уже писали: https://habr.com/ru/post/599669/
По сравнению с оригинальной задумкой стало больше элементов (с 8 до 26 для английск ого языка и 33 для русского). Но в качестве ограничения выступает то, что ответ - существующее слово из заранее известного словаря, а не случайная комбинация.
Я в детстве любил эту игру, и потестив, понял, что стратегия не поменялась по сути: сделав первое слово, где все буквы разные, я за 3 хода последовательно отдгадал.
Спасибо автору за разбор, но видно, что он не знал о Логике )
Кстати, отдельное спасибо за инфу о том, что словарь не так уж большой и собран вручную, не знал ?
Зависит от размера компании. Думаю, условный Эппл вполне себя видит через 5 лет )
У меня на практике про "кем себя видите?" спрашивали буквально пару раз может, сейчас этот вопрос уже выпилили из своего списка HRы. И спрашиали про 1 год - вполне нормальный горизонт планирования жизни любого уважающего себя работодателя, даже вчерашнего стартапа. Отвечал что-то стандартное типа "тим-лидом направления / начальником отдела".
Как минимум зайти на сайт и посмотреть с чем работает компания важно. Если идти "вслепую", то можно потратить своё время зря (время компании кандидату совершенно неинтересно, тут речь только про человека).
То есть при просмотре вакансии сложилось впечатление одно, а посмотрел профиль компании, может, отзывы о ней - и совсем другое. Или компания работает в сфере, неинтересной кандидату, не указав этого в вакансии (например, если человек не хочет работать в сфере торговли мясными изделиями, т.к. он вегетарианец). Пример утрирован, но это тоже влияет на образ компании в сознании кандидата.
Я не защищаю HR, они бывают сильно разные, особенно бесит, когда они совершенно не понимают ничего в вакансии и хлопают глазами, хотя бы образное начальное понимание должно быть, это сильно повышает в клазах кандидата позитивное отношение сразу с порога )
Если только из-за этого не взяли, то странная контора. Наоборот, раз их прорекламировали сарафанным радио, то значит, типа похвалили, радоваться должны. Я бы ещё уточнил на их месте: "И что о нас рассказали?, На какой позиции ваш знакомый работает/работал/или как узнал о нас сам?".
Понимать каналы распространения информации о компании всегда интересно.
Я о чём и говорю: можно даже если попсовый вопрос, не злиться, а проявить находчивость )
А новость о том, что в стрессовой ситуации человек не может или боится проявить смекалку/юмор/инициативу и делает то, что проще всего: врёт. Можно даже честно сказать: вопрос [текст вопроса] слишком типовый, вот вам типовый ответ, и дальше самый попсовый ответ )
Не всегда и не только.
Вопрос "кем вы себя видите?" помогает понять, что интересно из направлений деятельности потенциальному кандидату, что может помочь в предложении немного другой должности если он не стопроцентно проходит на собеседуемую. Но да, вопрос весьма попсовый и подбешивает.
По делу спрашивать должен уже технический специалист (будущий начальник и/или ментор).
Вопрос про компанию вообще, имхо, правильный, ведь если человек совершенно не поинтересовался, куда он идёт устраиваться, значит, в работе он тоже может быть часто таким же пофигистом. Хотя бы сайт открыть компании и посмотреть, чем занимается, и каковы отзывы в инете о ней если они есть, как минимум из здорового любопытства. А в мой отдел приходили общаться пару раз такие, которые даже сайт не открывали ?
В статье смешалось тёплое с мягким: заголовок о написании туториалов (aka мануалов, документаций, руководств), а текст - про нелюбовь автора к написанию их по ГОСТам.
По сути стиль написания инструкций зависит от сферы деательности компании и необходимости в этих самых ГОСТах. Ведь если нет задачи попасть в реестр Минсвязи и компания не работает с госконторами, то и нет необходимости придерживаться вообще каких-то ГОСТов. Пишите как нравится и чтобы было понятно клиентам. Можно даже с некоторой долей юмора, если позволяет корпоративная этика и специфика продукта?
Лично у меня по опыту приходилось писать и ближе к ГОСТам, и попроще - ближе к народу. Ну и опять же, лучше в случае крупных продуктов разделять инструкции к ним и статьи об их использовании в различных ситуациях с подробными примерами.
А как статьи на Хабр писать - на самом же Хабре уже сломано миллионы копий и написаны десятки статей.
А тут нужна обратная связь от пользователей. В моём случае помогает общение с тех.поддержкой, и большая часть предложений по улучшению и дополнению как документации, так и статей базы знаний приходит именно от них. То есть появляются более-менее похожие тикеты, значит, тема либо не освещена, либо освещена не теми фразами и она не находится на вебах (поисковики свою работу сделали, проиндексировали, а фразы не те, что используются при поиске).
Благодаря такому двухстороннему общению появляются актуальные (за это отвечает мой отдел тех.писателей, следя постоянно за обновлением решений), так и полезные (о чём рапортует тех.поддержка) мануалы.
А статьи базы знаний у нас - это отдельная сущность, которая раскрывает некоторые кейсы по использованию решений. То есть в документации - что может продукт и какие предоставляет настройки с некоторыми простыми примерами, в статьях - уже более сложные примеры кейсов, для чего могут понадобиться те или иные настройки.
Спасибо за пояснения, логика в решении проблемы действительно очевидна, просто обидно может быть, что кому-то ушло в минус. Хоть я и недавно тут, но полезно. Жаль, что изначально не сделали такой очевидный подход. Ещё бы убрать разделение кармы и рейтинга и оставить один понятный коэффициент "адекватности и полезности автора".
Автору можно и в статью данное объяснение добавить, было бы полезно другим, дабы не листать комментарии и не искать.?
Судя по фото, на материнке есть M.2 слот. Есть информация, он SATA или PCIE? Кто-то тестировал его на производительность с современными SSD?
Вроде этого вопроса не было в обсуждении выше.
Учитывая производительность ЦП, конечно, ему вполне хватит и SATA3, но интересно же ?
Изложу свои мысли по этому поводу, их самих на отдельную статью, но постараюсь кратко.
Со статьёй согласен, в полностью отечественной электронике всё примерно так и есть, не очень весело. А то, что работает – делается за рубежом.
Не вдаваясь в политику, приведу кое-какие соображения в дополнение к автору. Последний абзац выглядит как крик одинокого странника в пустыне, и оно и понятно ) Что же можно было бы сделать, и на что хорошее можно надеяться?
Всё-таки не так везде всё плохо. Как я уже упоминал, есть свои Эльбрусы, а ещё есть Байкалы. Да, делаются за рубежом на TSMC. Не надо ссориться ещё и с Тайванем, что тут сказать ))). Ещё есть контроллеры Овен, например, но там весь внутряк зарубежный, что подтверждает тезис статьи о том, что раз оно работает неплохо, то собрано не из местных чипов. К сожалению, пока так и получается...
В ПО дела обстоят таки веселее. И я не об «отечественных ОС», которые явно не состоят на 90% из накрученного на Linux-ядро криптографического и прочего одобренного ПО. Я о вполне неплохих и не менее, а то и более функциональных, чем забугорные аналоги, продуктах. Например, чем можно гордиться: любое ПО и поиск от Яндекса (тут без комментариев), комплекс решений для видеосвязи TrueConf (лидер в РФ и весьма известный за рубежом), офисный пакет Мой Офис (например, обзор посвежее и обзор тут же на хабре), бухгалтерское и прочее ПО от 1С, очень неплохой SCADA-пакет TraceMode (сам его юзал на прошлой работе, есть огрехи, но в общем хорош, у него живое коммьюнити, и проводят даже по нему олимпиады, и его изучают в ВУЗах), и много чего ещё. Для создания ПО нужны не такие бешенные сроки и заводы за миллиарды денег, как для чипов, так что тут попроще.
Как мне кажется, корни проблемы отставания в IT и электронике не в политике. Как уже писали в комментариях, в Японии есть свои компоненты, хоть и не делаются в таких кол-вах как китайские. Но они есть и наверняка качественные, а не как в статье. Опять же, Китай освоил штамповку своих процессоров как на полностью своей архитектуре, так и на купленной у AMD архитектуре Zen (и да, Хайгоны тоже штампуют на TSMC). Почему они могут? Дело начинается с самого детства в прямом смысле слова – с образования и науки. Подробно эта проблема рассмотрена в статье господина @3Dvideo «О русской науке…».
Пример из личного опыта
Насколько сейчас всё грустно в проблеме заинтересовать детей в массе что-то делать руками и узнавать новое, я недавно понял сам. У меня есть подруга – школьный учитель информатики. И она же по совместительству смотрит за парком техники в классах, обновляет ПО, чистит от шаловливых ручек детей и пр. В том числе пересобирает ПК и ноуты и иногда просит меня помочь. Я, как человек иногда занятой, как-то сказал ей: «Слушай, а что, из старшеклассников никому не интересно комп разобрать-собрать, помочь поковырять, узнать что-то новое о компонентной базе там и прочее?». На что последовал ответ: «Это у вас такие ещё были дети, 15 лет назад, сейчас они ленивы, инертны, торчат в мобилах и им неинтересно пыльные компы разбирать». То есть проблема идёт ещё со школы, что надо уже там уметь так поставить процесс, чтобы заинтересовать какую-то долю будущих айтишников. И начать с переработки программ, подходов к обучению, учебников и т.п.
Даже откинув политическую составляющую про защиту от внешнего мира и готовность к обрыву всех связей с поставщиками, иметь на своей территории производство важных компонентов тоже хорошо. Тут и возможность развивать своих специалистов (а то получается, что спецы в микроэлектронике и прочем только Китай с США), и побороться за какой-то рынок, может, что-то да изобрести. При должном отношении к качеству – уменьшить цепочки поставок, убрать зависимость от погоды и эпидемий, которые влияют на поставки через полпланеты. В общем, много плюсов даже в условиях мирного сосуществования. США вот озаботились этим вопросом, понятно, что с точки зрения предварительной защиты, но как я считаю, это полезно и в мирную эпоху. Вообще, к чему может привести сосредоточение производства чего-то важного в одном месте, можно увидеть на примере HDD и наводнения в Таиланде.
Кстати, "социальная леность" - это эффект Рингельмана, снижение индивидуальной производительности в группе, более 100 лет уже известное и в дальнейшем неоднократно доказанное и вне собственно мозгового штурма.