Докладчик рассказывает материал, попутно зачитывая то, что уже и так написано на экране...
Добавлю:
Автор постоянно листает слайды туда-сюда ("ну типа тут и так все понятно"), слайды в разных презентациях и повествование получается рваным
Автор зачитывает текст на слайде, а не рассказывает про особенности тех или иных ситуаций
Есть еще один момент, на котором я стал настаивать при прохождении курсов - предоставить мне слайды заранее, чтобы я мог по ним немного подготовиться и идти на лекцию с вопросами. Но так мало кто делает.
Вообще, мое общее требование к любому курсу - понятный на выходе конспект. Либо автор поможет мне его сделать в ходе лекции, либо предоставит уже систематизированный материал. Если такого не происходит, то считаю курс провальным.
Не уверен, что полноценно совмещать системного и бизнесового аналитика - хорошая идея. Водитель и механик - разные роли, но один немного должен понимать работу другого, иначе как систему создавать
Спасибо, что не спросили про языки программирования, т.к. анализ данных же можно делать только в коде. Первый инструмент - это голова, без нее работать сложно. Однажды от руководителя проектного отдела услышал фразу "а зачем БА нужно знать SQL"....
Все материалы давным давно доступны в виде текста, бери и читай, делай выжимки, озвучивай при помощи той же нейросети в конце концов.
Был однажды печальный опыт, когда на лекции ходить было нужно ради зачета (проверяли посещаемость), но вот препод откровенно читал по учебнику. Спрашивается, зачем?
Вот именно, что на лекциях приучают писать быстрей-быстрей. Получается, что ты не можешь ни слушать (надо же писать!), ни писать, т.к. быстро - это каракули, которые потом читать невозможно.
Ну это в платину! Вообще странно, что все само не работает.
Если хотя бы на один из этих вопросов нет чёткого ответа — ясности у вас не будет
Первое, на что бы я обратил внимание - наличие лица, способного принимать решения и понимать, какие именно решения придется принимать, даже если они не совсем "удобные".
Где-то на просторах Хабра не очень хорошо отзывались о RACI (за себя скажу, что читается она тяжело).
А почему нет? Далеко не все оказались в своей профессии осознанно, часто это просто вопрос инерции. Здесь же нет истории про переход туда, где больше платят и подводка вполне логичная. Автору зачёт.
Удивительно, но у меня был ровно противополоный опыт, когда надо было описывать чисто программерские алгоритмы, о которых ни мне, ни заказчику знать совершенно необязательно.
Самый неудобный вопрос - руководителю: а в чем была его роль в отделе?
Не стоит сваливать всю работу на уходящего человека, следует делегировать запись и документирование материалов другим членам команды. Пусть каждый изучает и берет на себя часть зон ответственности.
Пусть члены команды, например, попробуют выполнить реальные задачи, опираясь только на новую документацию.
Ага, щаз, если в компании проблема с передачей знаний, значит там же и проблема с выделением таких ресурсов.
Не нужно пытаться вытащить из эксперта абсолютно всё.
Да он может и не захотеть: "мне за это не платят", - и что тогда?
Найдешь ссылку?
Не факт, у меня был такой преподаватель в институте - просто подошел к задаче формально. Мы ему также и зачет сдавали, но важна была посещаемость
Добавлю:
Автор постоянно листает слайды туда-сюда ("ну типа тут и так все понятно"), слайды в разных презентациях и повествование получается рваным
Автор зачитывает текст на слайде, а не рассказывает про особенности тех или иных ситуаций
Есть еще один момент, на котором я стал настаивать при прохождении курсов - предоставить мне слайды заранее, чтобы я мог по ним немного подготовиться и идти на лекцию с вопросами. Но так мало кто делает.
Вообще, мое общее требование к любому курсу - понятный на выходе конспект. Либо автор поможет мне его сделать в ходе лекции, либо предоставит уже систематизированный материал. Если такого не происходит, то считаю курс провальным.
Вот поддержу, что ни новость, то перечень версий каких-то пакетов, то есть автор никак не опробовал на себе пользовательский опыт. Пост ради поста.
Не уверен, что полноценно совмещать системного и бизнесового аналитика - хорошая идея. Водитель и механик - разные роли, но один немного должен понимать работу другого, иначе как систему создавать
Спасибо, что не спросили про языки программирования, т.к. анализ данных же можно делать только в коде. Первый инструмент - это голова, без нее работать сложно. Однажды от руководителя проектного отдела услышал фразу "а зачем БА нужно знать SQL"....
Был однажды печальный опыт, когда на лекции ходить было нужно ради зачета (проверяли посещаемость), но вот препод откровенно читал по учебнику. Спрашивается, зачем?
Вот именно, что на лекциях приучают писать быстрей-быстрей. Получается, что ты не можешь ни слушать (надо же писать!), ни писать, т.к. быстро - это каракули, которые потом читать невозможно.
Увы, но "просто ходить" недостаточно, даже вверх по эскалатору (хотя это тоже неплохо).
Ну это в платину! Вообще странно, что все само не работает.
Первое, на что бы я обратил внимание - наличие лица, способного принимать решения и понимать, какие именно решения придется принимать, даже если они не совсем "удобные".
Где-то на просторах Хабра не очень хорошо отзывались о RACI (за себя скажу, что читается она тяжело).
Интеллект эз э сёрвиз, AIaaS?
Отличный подход и пример с мебелью, но как это реализовано? (можно не про конкретный инструмент, а методику действий)
А почему нет? Далеко не все оказались в своей профессии осознанно, часто это просто вопрос инерции. Здесь же нет истории про переход туда, где больше платят и подводка вполне логичная. Автору зачёт.
Еще хуже, когда есть только видеокурс и без таймкодов.
Удивительно, но у меня был ровно противополоный опыт, когда надо было описывать чисто программерские алгоритмы, о которых ни мне, ни заказчику знать совершенно необязательно.
Про требования, которые будут читать уже была статья: Простые способы улучшить читаемость функциональных требований
И добавьте, пожалуйста, заголовки про "нарушение метрик" - должно быть нагляднее.
Вот этим пользуюсь регулярно, "рисовать" после текста очень полезно.
Самый неудобный вопрос - руководителю: а в чем была его роль в отделе?
Ага, щаз, если в компании проблема с передачей знаний, значит там же и проблема с выделением таких ресурсов.
Да он может и не захотеть: "мне за это не платят", - и что тогда?
Вся статья про успехи в бизнесе, но мне интереснее самое начало - почему так вообще сложилось.
Я бы ориентировался не на ИТ, а на роль (или направление), где это будет выгоднее когда выучишься или ситуация в мире изменится - уже не так важно.
Так это про производство, а не про улучшение навигации (и передачу информации).
Еще вот что заметил - а причем тут ИТ?