И вот личная профильная статистика за последние 7 лет к сожалению не дала ни одного "самоучки", который бы дорос до senior, но дает несколько примеров с вышкой.
Мне кажется, что тут смещённая ошибка выжившего.
Люди, которые дорастают до сеньоров (в моей области и по моей оценке) в принципе более склонны к систематизации, к расширению известных предметных областей, развитию навыков и прочее. Эта склонность, в свою очередь, является заслугой сохранённого любопытства и здоровья личности. Так случается, что родители, воспитывающие таких детей, могут чаще себе позволить качественное образование (а кормить неработающего оболтуса - тоже труд).
Иными словами, в среднем у людей с ВО больше шансов дойти до высшего специалитета не из-за самого факта наличия этого ВО, а из-за достатка и адекватности родителей. Насколько эти факторы статистически значимы - надо ещё изучать.
Поэтому, по-хорошему, бизнес должен говорить специалисту (немного обесценивая при этом его усилия):
Нам дешевле ввести статистически вроде работающий критерий и потерять хорошего кандидата без ВО, чем потратить ресурсы на нормальный отбор
Вместо этого он говорит (делая специалиста ещё и виноватым):
Если ты не соответствуешь выбранному нами критерию - ты идиот и бездарь, который не смог потратить время на то, чтобы нам понравиться
Обычно именно это лицемерие, созданное из предрассудков, и является причиной раздражения соискателей.
P.S. ВО есть, трудовая работает на меня, просто кучу людей, которые несмотря на жизненные ситуации стараются и прикладывают усилия для встречи с такой некомпетентностью жалко. Это как если софтскиллы по соционике или гороскопу проверять.
Когда ты прописываешь задачи на день, ты идешь от конца, смотришь «чем я могу тут помочь» и если есть что-то, что надо сделать, ты добавляешь себе задачку в план. И так идешь к началу воронки.
Да, выхлоп от действий снижается, но эти действия тоже необходимы, так как тебе нужно продвигать всю воронку в целом - если ты будешь двигать только конец воронки, то скоро воронка встанет.
Типичный пример того, как человек ознакомился с, в общем-то, неплохой (хотя и хорошей назвать не могу) теорией, но вместо понимания основной идеи просто криво адаптировал технику к практике.
Теория ограничений, она, как следует из названия, про ограничения. Про то, что нужно устранять самое узкое горлышко в процессе. И любой, как мне кажется, знакомый с процессом найма (с любой из сторон), основной болью назовёт соответствие кандидата позиции. Следовательно, работать надо над способами быстро и эффективно понять подходит ли кандидат компании и подходит ли компания кандидату.
Рекрутер же вместо этого подменяет цель (найм подходящего человека --> найм), т.к. его премия зависит именно от этого. Ему без разницы на время кандидатов, на время нанимающего менеджера, собеседующих, ресурсы компании и что бы то не было. И рекрутера тут абсолютно не за что винить: он просто рядовой сотрудник и премию устанавливал не он (только не воспринимайте это как совет ставить рекрутеру KPI в потраченных человекочасах).
Поэтому в большинстве компаний эффективного процесса найма нет и не будет: человек работу работать нужен уже сейчас, как определять подходящего мы не знаем, да и ресурсы не бесконечные. Так же не будет и эффективного процесса трудоустройства со стороны соискателей: работу зовут работать уже сейчас, компании примерно одинаковы, да и объём заначки не бесконечный.
Не уверен, что у этой проблемы есть решение, т.к. хорошие вакансии привлекают дилетантов, а хорошие резюме скринятся роботами. Но, хочется верить, что всё-таки как-то улучшить его можно.
Там, где цена ошибки аналитика слишком высока, его не распыляют на смежные роли: пусть уж лучше занимается только требованиями, зато занимается хорошо.
Для этого должно быть выполнено несколько условий:
Команда разработки достаточно большая и занимается достаточно схожими вещами: свободного специалиста можно подключить на смежные проекты
Компания в своём развитии и процессах дошла до разделения ролей по специалитету (архитектура на архитекторе, дизайн на UX/UI-проектировщике, тесты на тест-менеджере, CI/CD на DevOpsах и т.д.), т.к. подобных специальных задач надо решать настолько много, что выгоднее нанять отдельного специалиста
Компания может себе позволить нанимать лучших специалистов, которые помогут настроить процессы, сферы компетенций, разделение ответственности и пр.
Компания готова меняться ради большей эффективности бизнеса: локальная политика (мелкие начальники) или традиции не являются значительной преградой
Лично на моей (достаточно малой в плане разнообразия) рабочей практике - это выполняется только в продуктовом ИБ.
P.S. А вот примеров, где необходимо разделение бизнес-анализа и системного анализа, я в продуктовой разработке так и не встречал: кажется, что это больше заказная тема.
О, прогрессивные технологии рекрутинга. Считаю, что нужно соискателю ещё и оплачивать время всех специалистов с учётом издержек на отвлечения, согласования и коммуникацию (включая работу эйчаров). А то тратит, понимаешь, время работы специалистов. Ещё и вопросами не дай бог отвлекает, тогда вообще штрафовать надо.
Т.е. я, как системный аналитик, должен не только совмещать роли собственно аналитика и архитектора (а может, и ещё какие-то):
На этом этапе мы даем кандидату конкретные задачи. Например, предлагаем смоделировать систему. Или показываем два сервиса и говорим: здесь есть интеграция, с ней такие-то проблемы, как вы их решите
за зарплату одного лишь аналитика, но и ещё должен потратить минимум 3.5 часа своего времени ради "собеседования мечты"?
Спасибо за предупреждение, теперь буду отказывать вашим эйчарам ссылаясь на эту статью.
Задача аналитика - спроектировать интерфейс или пользовательское взаимодействие? Это далеко не везде так и об этом не сказанно явно. Для какого именно спектра задач требуется знание различий?
Речь идёт про стайлгайды, "общепринятые модели поведения" или доступные элементы дизайна? В любом случае, не хватает ссылок на источники, почему описанные различия выглядят так, стоит ли им следовать и если нет - то для чего.
Для каких версий всё это актуально, для каких оболочек (в случае андроида)? Тот же андроид по умолчанию не даст сохранить файл вне пользовательского пространства. Если уж давать различия, то явно: Smart Lock появился с 5 версии, завязан на гугл сервисы, может быть отключён для отдельных приложений...
Если это просто обзорная статья о том, что различия есть и если вам вдруг нужно о них знать, то вот краткий список, дальше гуглите сами - окей, в таком виде к ней вопросов нет.
Если это единственное отличие, на ваш взгляд, то Use case - актуальная версия описания функциональности на Confluence, а User stories - каждый отдельный коммит (правка) и в самой первой версии они совпадают.
Я же хотел бы обратить внимание на структурные изменения вашей истории с учетом ориентирования на клиента в сравнении с классической user story (не говоря уж про усечённые): в ней сильно меньше от user story, но значительная часть от use case. Ну окей, живёт не вечно и не актуализируется (как и отдельная версия страницы на confluence), в остальном же это скорее use case.
Значит, менеджмент и HR достаточно адекватны, чтобы не прикрываться формальными процессами и эксплуатировать их слабые стороны, это радует. Спасибо за ответ, держите в курсе, если что изменится :)
Вообще, ответ K_Chicago выглядит правдоподобно. Сейчас попробую объяснить, почему так.
Классическая схема полного цикла действий, когда нужно сделать хорошо и чтобы кнопочка красная выглядит следующим образом:
Определить всех заинтересованных лиц и их роль в принятии решений (т.к. людей много, работаем с их классами)
Собираем с них требования
Проверяем требования на полноту (очевидные самоподразумевающиеся требования вроде работы без электричества) и непротиворечивость (отсутствие разных интересов)
При наличии противоречий (т.е. всегда) собираем совещание и доводим людей до разрешения противоречий
При неполноте требований (т.е. всегда) идём к основным заказчикам и пугаем их цифрами про стоимость SLA в 98%, 99.5, 99.9, 99.99 и т.д., определяя какие именно НФТ к продукту у них
Собираем всё это в единый документ (итоги совещания, концепция доработки, BRQ List, whatever) и докапываемся до всех с просьбой вдумчиво прочитать и согласовать, обозначив сроки автопринятия документа (т.к. читать всё равно не будут)
Идём к архитектору/проджекту/лиду/случайному разработчику и просим на основании этого документа дать оценки: возможно ли это сделать в принципе (очевидные вещи надо было ещё на этапе совещания отсечь ибо стыдно), как можно сделать это проще, быстрее и дешевле и чем именно для этого нужно пожертвовать
Учитывая ограничения системы, интеграций, регламентов и прочего - создаём документ для разработки с описанием системы и предполагаемой архитектурой, полученной на предыдущем этапе
Собираем разработчиков, проводим демо требований, оперативно заносим всю критику и исправления в документ, просим их примерно оценить сроки работы
Возвращаемся к заказчиком с оценкой, наблюдаем никогда не надоедающую сцену "Я думал тут работы на час, всего кнопочку добавить", проводим раунд торгов по требованиям и определяем MVP с приоритетами
Радуем разработчиков, что вместо велосипеда с турбореактивным двигателем достаточно велосипеда с двс о семи колёсах, расписываем требования для разработчиков
Мужественно отвечаем на возникшие вопросы
Как оно выглядит со стороны:
1, 3, 12 - пить кофе и заниматься произвольными делами
2, 5, 7, 10 - отвлекать занятых людей глупыми вопросами
Вы и так почти всё назвали :) Кроме самого распространённого и действенного метода - запереть в кладовке собрать вместе на совещании и закрыть дверь изнутри вести это совещание для выработки устраивающего всех решения. Дальше всё зависит от ведущего встречу (скорее всего, серию встреч): насколько он может гасить конфликты, держать разговор в конструктивном русле не отклоняясь от повестки и прочее.
И да, и нет. Идеальное требование с моей точки зрения не существует, т.к. является лишь моделью реальности. Тут как с кодом, если можно обойтись имеющимся - это лучший сценарий. А дальше уже можно составлять достаточно хорошее требование по критериям.
Лучше уж спросить определение стейкхолдера (или ЗЛ) или углубиться в тонкости "лицо" vs "сторона"
Да, пожалуй. Я вёл лишь к тому, что не все заинтересованные лица (например - злоумышленники) должны участвовать в постановке требований, но это не означает, что из их потребностей не могут быть созданы требования. Разговор про тонкости "лицо" vs "сторона" привносит ещё и подтекст корпоративной политики, поэтому будет интересней.
Что вы будете делать, если требование поступило максимально сырым?
Чем стейкхолдеры отличаются от заинтересованных лиц (спорный вопрос про долю участия в проекте)?
Как вы определяете состав MVP?
Какие бы вопросы вы задали (вы задавали) другому аналитику на собеседовании?
Какое требование вы бы назвали идеальным и почему?
Плюс, было ещё энное количество вопросов из смежных ролей (так, вопросы из IV SQL и базы данных я отношу к роли DBA, из V Интеграция - к роли архитектора):
дата аналитики (оптимизация взаимодействия исходя из логов)
UX/UI (какие UX принципы знаете)
безопасности (как обеспечить защищённый доступ для сотрудника вне корпоративного контура)
...
да даже разработки!
Не назвал бы их вопросами на стэк или домен, это обычное и естественное желание возложить роль специалиста N на специалиста M, потому что для найма N есть препятствия (задач почти нет, достаточно базовой компетенции, начальство экономит на сотрудниках...)
Сравнивая пункт 1.1 и 1.2 кажется, что тусовка важнее контента. Конечно, пункт 1.3 заявляет, что право ещё важнее, но хотелось бы понять как оно на самом деле.
Да и пункт 7 вашей оферты выглядит немного странно с точки зрения обывателя: будто при желании вы можете сами устанавливать сумму периодического пожертвования.
В общем, больше прозрачности с финансовой стороны точно не помешает: что такое викимедиа.ру и почему она отдельно, какова финансовая статистика обоих организаций и почему, на что идут донаты российскому сообществу (желательно с примерами золотых статей) и так далее.
Жертвуя википедии ты жертвуешь, хм, википедии. Жертвуя российскому отделению — кому и за что ты жертвуешь?
Вроде он, сейчас уже и не вспомню точно, но там была онлайн-схемотехника, все примеры сразу же иллюстрировались и задачи были на этом же симуляторе. Вполне себе качественная и доступная замена стенда, который не везде доступен. Это не скачок, конечно, но улучшение, сказывающееся положительно на доступности качественных знаний.
Не очень понятно, правда, зачем при доступности этих курсов плодить менее качественные альтернативы, но поскольку курсы ставят своей целью не образование, а прибыль, то имеем что имеем ¯\_(ツ)_/¯
Под рекламой курса консалтинга на самом деле скрывается тренинг по вскрытию комплексов и личностному росту. После окончания люди открывают для себя новые истины, переходят к более позитивному мышлению. Однако если бы они прочитали в описании, что же реально им продадут, точно посчитали бы это ерундой. Они просто не стали бы это покупать. Вот вам парадокс: описание содержанию не соответствует, но все довольны.
По мне, это один из главных отталкивающих факторов, после неопределённости результата (стоит ли оно того). До витка популярности онлайн-образования, если я слушал курс по CS от MIT или по сетям, я был уверен в наполнении курса. Сейчас я вижу описание, вроде бы всё по делу, но т.к. автором курса может стать практически любой человек (в зависимости от платформы), то описание курса может абсолютно не соответствовать его содержанию.
В классических образовательных программах это как-то решилось репутацией: образовательные программы могут быть код в код, но один институт явно сильнее другого. Репутация тоже так себе выход (тот же модерируемый рейтинг), но если углубляться в эту тему — всё станет сильно сложнее.
P.S. Единственный онлайн-курс, который оставил после себя хорошее впечатление — курс MIT по электротехнике, который я пробовал пройти в 9 классе и бросил на 4 неделе из-за недостатка знаний в высшей математике. Остальное — либо неплохие лекции, либо материалы с конференций, либо обучение от Trainee до Junior в лучшем случае. Так что к онлайн-образованию я отношусь скептически, хоть и меня самого звали его вести, и сам я его пробовал, и знакомым для примерки рекомендовал.
В принципе, могу рассказать про бизнес и системную аналитику:
ситуацию на отечественном рынке,
связь требуемых навыков с уровнем зрелости IT в компании,
почему всё плохо и лучше не скоро будет,
почему аналитики всегда будут нужны,
чему вообще учиться, если пришлось брать на себя эту роль,
на что обращать внимание при собеседовании (с обоих сторон),
почему аналитик и менеджер (как проекта, так и продукта) должны быть немного взаимозаменяемы
что-нибудь ещё
Мне кажется, что тут смещённая ошибка выжившего.
Люди, которые дорастают до сеньоров (в моей области и по моей оценке) в принципе более склонны к систематизации, к расширению известных предметных областей, развитию навыков и прочее. Эта склонность, в свою очередь, является заслугой сохранённого любопытства и здоровья личности. Так случается, что родители, воспитывающие таких детей, могут чаще себе позволить качественное образование (а кормить неработающего оболтуса - тоже труд).
Иными словами, в среднем у людей с ВО больше шансов дойти до высшего специалитета не из-за самого факта наличия этого ВО, а из-за достатка и адекватности родителей. Насколько эти факторы статистически значимы - надо ещё изучать.
Поэтому, по-хорошему, бизнес должен говорить специалисту (немного обесценивая при этом его усилия):
Вместо этого он говорит (делая специалиста ещё и виноватым):
Обычно именно это лицемерие, созданное из предрассудков, и является причиной раздражения соискателей.
P.S. ВО есть, трудовая работает на меня, просто кучу людей, которые несмотря на жизненные ситуации стараются и прикладывают усилия для встречи с такой некомпетентностью жалко. Это как если софтскиллы по соционике или гороскопу проверять.
Типичный пример того, как человек ознакомился с, в общем-то, неплохой (хотя и хорошей назвать не могу) теорией, но вместо понимания основной идеи просто криво адаптировал технику к практике.
Теория ограничений, она, как следует из названия, про ограничения. Про то, что нужно устранять самое узкое горлышко в процессе. И любой, как мне кажется, знакомый с процессом найма (с любой из сторон), основной болью назовёт соответствие кандидата позиции. Следовательно, работать надо над способами быстро и эффективно понять подходит ли кандидат компании и подходит ли компания кандидату.
Рекрутер же вместо этого подменяет цель (найм подходящего человека --> найм), т.к. его премия зависит именно от этого. Ему без разницы на время кандидатов, на время нанимающего менеджера, собеседующих, ресурсы компании и что бы то не было. И рекрутера тут абсолютно не за что винить: он просто рядовой сотрудник и премию устанавливал не он (только не воспринимайте это как совет ставить рекрутеру KPI в потраченных человекочасах).
Поэтому в большинстве компаний эффективного процесса найма нет и не будет: человек работу работать нужен уже сейчас, как определять подходящего мы не знаем, да и ресурсы не бесконечные. Так же не будет и эффективного процесса трудоустройства со стороны соискателей: работу зовут работать уже сейчас, компании примерно одинаковы, да и объём заначки не бесконечный.
Не уверен, что у этой проблемы есть решение, т.к. хорошие вакансии привлекают дилетантов, а хорошие резюме скринятся роботами. Но, хочется верить, что всё-таки как-то улучшить его можно.
Где как, на самом деле.
Там, где цена ошибки аналитика слишком высока, его не распыляют на смежные роли: пусть уж лучше занимается только требованиями, зато занимается хорошо.
Для этого должно быть выполнено несколько условий:
Команда разработки достаточно большая и занимается достаточно схожими вещами: свободного специалиста можно подключить на смежные проекты
Компания в своём развитии и процессах дошла до разделения ролей по специалитету (архитектура на архитекторе, дизайн на UX/UI-проектировщике, тесты на тест-менеджере, CI/CD на DevOpsах и т.д.), т.к. подобных специальных задач надо решать настолько много, что выгоднее нанять отдельного специалиста
Компания может себе позволить нанимать лучших специалистов, которые помогут настроить процессы, сферы компетенций, разделение ответственности и пр.
Компания готова меняться ради большей эффективности бизнеса: локальная политика (мелкие начальники) или традиции не являются значительной преградой
Лично на моей (достаточно малой в плане разнообразия) рабочей практике - это выполняется только в продуктовом ИБ.
P.S. А вот примеров, где необходимо разделение бизнес-анализа и системного анализа, я в продуктовой разработке так и не встречал: кажется, что это больше заказная тема.
О, прогрессивные технологии рекрутинга. Считаю, что нужно соискателю ещё и оплачивать время всех специалистов с учётом издержек на отвлечения, согласования и коммуникацию (включая работу эйчаров). А то тратит, понимаешь, время работы специалистов. Ещё и вопросами не дай бог отвлекает, тогда вообще штрафовать надо.
Т.е. я, как системный аналитик, должен не только совмещать роли собственно аналитика и архитектора (а может, и ещё какие-то):
за зарплату одного лишь аналитика, но и ещё должен потратить минимум 3.5 часа своего времени ради "собеседования мечты"?
Спасибо за предупреждение, теперь буду отказывать вашим эйчарам ссылаясь на эту статью.
Статья кажется немного недоделанной:
Задача аналитика - спроектировать интерфейс или пользовательское взаимодействие? Это далеко не везде так и об этом не сказанно явно. Для какого именно спектра задач требуется знание различий?
Речь идёт про стайлгайды, "общепринятые модели поведения" или доступные элементы дизайна? В любом случае, не хватает ссылок на источники, почему описанные различия выглядят так, стоит ли им следовать и если нет - то для чего.
Для каких версий всё это актуально, для каких оболочек (в случае андроида)? Тот же андроид по умолчанию не даст сохранить файл вне пользовательского пространства. Если уж давать различия, то явно: Smart Lock появился с 5 версии, завязан на гугл сервисы, может быть отключён для отдельных приложений...
Если это просто обзорная статья о том, что различия есть и если вам вдруг нужно о них знать, то вот краткий список, дальше гуглите сами - окей, в таком виде к ней вопросов нет.
Если это единственное отличие, на ваш взгляд, то Use case - актуальная версия описания функциональности на Confluence, а User stories - каждый отдельный коммит (правка) и в самой первой версии они совпадают.
Я же хотел бы обратить внимание на структурные изменения вашей истории с учетом ориентирования на клиента в сравнении с классической user story (не говоря уж про усечённые): в ней сильно меньше от user story, но значительная часть от use case. Ну окей, живёт не вечно и не актуализируется (как и отдельная версия страницы на confluence), в остальном же это скорее use case.
Или я где-то что-то понимаю не так?
Мне кажется, или вы начали модифицировать User story, а в итоге реализовали Use case?
Значит, менеджмент и HR достаточно адекватны, чтобы не прикрываться формальными процессами и эксплуатировать их слабые стороны, это радует.
Спасибо за ответ, держите в курсе, если что изменится :)
Вот и год прошёл. Как там система оценки поживает?
Вообще, ответ K_Chicago выглядит правдоподобно. Сейчас попробую объяснить, почему так.
Классическая схема полного цикла действий, когда нужно сделать хорошо и чтобы кнопочка красная выглядит следующим образом:
Определить всех заинтересованных лиц и их роль в принятии решений (т.к. людей много, работаем с их классами)
Собираем с них требования
Проверяем требования на полноту (очевидные самоподразумевающиеся требования вроде работы без электричества) и непротиворечивость (отсутствие разных интересов)
При наличии противоречий (т.е. всегда) собираем совещание и доводим людей до разрешения противоречий
При неполноте требований (т.е. всегда) идём к основным заказчикам и пугаем их цифрами про стоимость SLA в 98%, 99.5, 99.9, 99.99 и т.д., определяя какие именно НФТ к продукту у них
Собираем всё это в единый документ (итоги совещания, концепция доработки, BRQ List, whatever) и докапываемся до всех с просьбой вдумчиво прочитать и согласовать, обозначив сроки автопринятия документа (т.к. читать всё равно не будут)
Идём к архитектору/проджекту/лиду/случайному разработчику и просим на основании этого документа дать оценки: возможно ли это сделать в принципе (очевидные вещи надо было ещё на этапе совещания отсечь ибо стыдно), как можно сделать это проще, быстрее и дешевле и чем именно для этого нужно пожертвовать
Учитывая ограничения системы, интеграций, регламентов и прочего - создаём документ для разработки с описанием системы и предполагаемой архитектурой, полученной на предыдущем этапе
Собираем разработчиков, проводим демо требований, оперативно заносим всю критику и исправления в документ, просим их примерно оценить сроки работы
Возвращаемся к заказчиком с оценкой, наблюдаем никогда не надоедающую сцену "Я думал тут работы на час, всего кнопочку добавить", проводим раунд торгов по требованиям и определяем MVP с приоритетами
Радуем разработчиков, что вместо велосипеда с турбореактивным двигателем достаточно велосипеда с двс о семи колёсах, расписываем требования для разработчиков
Мужественно отвечаем на возникшие вопросы
Как оно выглядит со стороны:
1, 3, 12 - пить кофе и заниматься произвольными делами
2, 5, 7, 10 - отвлекать занятых людей глупыми вопросами
4, 9 - собрать совещание, лишь бы не работать
6, 8, 11 - написать документ по итогам встречи
? - работать
Вы и так почти всё назвали :) Кроме самого распространённого
и действенногометода -запереть в кладовкесобрать вместе на совещании изакрыть дверь изнутривести это совещание для выработки устраивающего всех решения. Дальше всё зависит от ведущего встречу (скорее всего, серию встреч): насколько он может гасить конфликты, держать разговор в конструктивном русле не отклоняясь от повестки и прочее.И да, и нет. Идеальное требование с моей точки зрения не существует, т.к. является лишь моделью реальности. Тут как с кодом, если можно обойтись имеющимся - это лучший сценарий. А дальше уже можно составлять достаточно хорошее требование по критериям.
Да, пожалуй. Я вёл лишь к тому, что не все заинтересованные лица (например - злоумышленники) должны участвовать в постановке требований, но это не означает, что из их потребностей не могут быть созданы требования. Разговор про тонкости "лицо" vs "сторона" привносит ещё и подтекст корпоративной политики, поэтому будет интересней.
Добавлю немного.
Какие виды сбора требований вы знаете?
В каком виде вам поступали задачи на аналитику?
Что вы будете делать, если требование поступило максимально сырым?
Чем стейкхолдеры отличаются от заинтересованных лиц (спорный вопрос про долю участия в проекте)?
Как вы определяете состав MVP?
Какие бы вопросы вы задали (вы задавали) другому аналитику на собеседовании?
Какое требование вы бы назвали идеальным и почему?
Плюс, было ещё энное количество вопросов из смежных ролей (так, вопросы из IV SQL и базы данных я отношу к роли DBA, из V Интеграция - к роли архитектора):
из тестирования (отличия blackbox от whitebox)
проектного/продуктового менеджмента (приоритезация фичей)
продуктовой аналитики (метрики востребованности фичи)
дата аналитики (оптимизация взаимодействия исходя из логов)
UX/UI (какие UX принципы знаете)
безопасности (как обеспечить защищённый доступ для сотрудника вне корпоративного контура)
...
да даже разработки!
Не назвал бы их вопросами на стэк или домен, это обычное и естественное желание возложить роль специалиста N на специалиста M, потому что для найма N есть препятствия (задач почти нет, достаточно базовой компетенции, начальство экономит на сотрудниках...)
Да и пункт 7 вашей оферты выглядит немного странно с точки зрения обывателя: будто при желании вы можете сами устанавливать сумму периодического пожертвования.
В общем, больше прозрачности с финансовой стороны точно не помешает: что такое викимедиа.ру и почему она отдельно, какова финансовая статистика обоих организаций и почему, на что идут донаты российскому сообществу (желательно с примерами золотых статей) и так далее.
Жертвуя википедии ты жертвуешь, хм, википедии. Жертвуя российскому отделению — кому и за что ты жертвуешь?
Алкоголь-то?
Не очень понятно, правда, зачем при доступности этих курсов плодить менее качественные альтернативы, но поскольку курсы ставят своей целью не образование, а прибыль, то имеем что имеем ¯\_(ツ)_/¯
По мне, это один из главных отталкивающих факторов, после неопределённости результата (стоит ли оно того). До витка популярности онлайн-образования, если я слушал курс по CS от MIT или по сетям, я был уверен в наполнении курса. Сейчас я вижу описание, вроде бы всё по делу, но т.к. автором курса может стать практически любой человек (в зависимости от платформы), то описание курса может абсолютно не соответствовать его содержанию.
В классических образовательных программах это как-то решилось репутацией: образовательные программы могут быть код в код, но один институт явно сильнее другого. Репутация тоже так себе выход (тот же модерируемый рейтинг), но если углубляться в эту тему — всё станет сильно сложнее.
P.S. Единственный онлайн-курс, который оставил после себя хорошее впечатление — курс MIT по электротехнике, который я пробовал пройти в 9 классе и бросил на 4 неделе из-за недостатка знаний в высшей математике. Остальное — либо неплохие лекции, либо материалы с конференций, либо обучение от Trainee до Junior в лучшем случае. Так что к онлайн-образованию я отношусь скептически, хоть и меня самого звали его вести, и сам я его пробовал, и знакомым для примерки рекомендовал.