Category: образование

Category was added automatically. Read all entries about "образование".

Разбор кейса “Командная работа – это когда вся команда делает так, как я говорю”

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

За поездками туда-сюда отложился разбор замечательного кейса “Командная работа – это когда вся команда делает так, как я говорю”. Давайте его таки разберем.

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

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

Момент №1. Четко формулируйте, чего вы хотите от начальника.

Меня в описании кейса зацепила фраза “Решили [рассказать] в лоб, честно, открыто, с целью заручиться поддержкой”. Что такое “заручиться поддержкой”? Вы начали рассказывать про свою идею. Вероятно, издалека. По описанию типа начальника это человек быстрый и решительный. Если он сразу не видит четкого описания проблемы, если он не видит, чего от него хотят, то он формулируют проблему сам. Причем уже в виде решения. :)

Здесь можно было бы попробовать сразу так и сказать: “Мы решили провести лекцию для коллектива. Долго думали над темой. В итоге выбрали А, поскольку эта тема в коллективе самая животрепещущая. Хотим заручиться вашей поддержкой, то есть, чтобы  Вы [четкая формулировка, чего вы от начальника хотите]“.

Момент №2. Факты для разговора.

На вторую встречу начальник предложил тему Б. Вы с этим выбором несогласны. Почему? Потому что вам кажется, что нужна другая тема. А ему кажется иначе. Как ему понять вас? Человеку нужны факты – почему ваша тема лучше чем его. Таким фактом могла бы стать, например, обратная связь от слушателей.

Простые заполненные анкетки. И там, в числе прочего, вопрос “Какая тема является самой важной для вас и вашей работы?” И с этими данными вы уже можете прийти к начальнику, и ему будет к чему прислушаться. Он, вполне вероятно, не может прислушаться к ощущениям подчиненных. Ему факты нужны.

Получится, не получится – надо будет посмотреть. Но я бы попробовал начать с этих двух моментов.

Кейс “Командная работа – это когда вся команда делает так, как я говорю”

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Очередной любопытный кейс постоянного читателя Happy-PM.com, автора кейсов “Какой же ты руководитель, если код не пишешь?” и “Лидер сам по себе”. Ситуация настолько же любопытна, насколько и типична:

Кейс “Командная работа – это когда вся команда делает так, как я говорю”

Небольшое предисловие.

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

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

В обсуждении этих тем у меня с ним прошло не мало времени. Я ему описывал то, что происходит у нас, к чему люди привыкли, вместе вырабатывали стратегию по внедрению “best practices”. Что-то начало сбываться, наша стратегия сработала, правильно поданные идеи были восприняты с должным энтузиазмом и начали воплощаться в жизнь.

И вот, в один день С. мне рассказывает – “В моей предыдущей компании была такая традиция – мы делали доклады, читали лекции, проводили мини-тренинги для своих сотрудников по интересам. Если кто-то хотел о чем-то рассказать или чему-то научить и находилось достаточное количество желающих, на это отводилось специальное время и место. У вас такое не принято, но ведь было бы здорово устроить. Более того, я вижу, что в здешних процессах можно улучшить и я готов прочитать лекцию, провести workshop, сделать что угодно для того, чтобы изменить все к лучшему.”

Где-то здесь начинается сам кейс :)

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

Описываю заведомо скептические отношение руководителя к таким начинаниям, общий настрой всей команды. Начинаем снова со стратегии и оформления идеи.Идея, думаю, не новая – Где-то в месте с общим доступом делается объявление формата “Наш коллега С. желает прочитать лекции для своих коллег на темы А,Б,В. Желающие послушать, пожалуйста, отметьте наиболее интересующие вас темы.” Коллектив делает свой выбор, затем проводится лекция либо мини-тренинг, в зависимости от необходимости.

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

Решили в лоб, честно, открыто, с целью заручиться поддержкой. Тут наша стратегия вместе с идеей дали трещину. П. (руководитель) нас выслушал, сказал “Лекция – это хорошо, значит, послезавтра прочитаешь на тему Б. У тебя будет час, все придут слушать. Никаких рассылок, опросов и прочих мнений не надо..” и следом разослал всем уведомление о предстоящем событии с “просьбой” присутствовать.

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

Объясняли по-разному – все темы нужные, но моей команде, например, не на столько нужна была выбранная П. лекция. Специфика работы такая, что мы с этим никогда не столкнемся на этом проекте, а для общей осведомленности были бы благодарны и за полезные ссылки. А вот по другой теме мы бы с удовольствием прошлись и хотели бы посерьезнее.

Никакого эффекта. Посовещавшись, мы с С. решили “выдать” всю задумку во вступительной части к первой лекции, рассказать о том, как мы хотим все сделать, к чему приглашаем всех членов команды.Решили – сделали. Подготовили “место с общим доступом” для тем, обратной связи, рассказали, провели лекцию, подняли множество вопросов в аудитории, возбудили немалый интерес к новшеству.

А тут вдруг бац! Под занавес П. сообщает – “Следующая лекция, я думаю, будет на тему А. Я думаю, это всем должно быть интересно.”

Это кейс по конкретному примеру на широкую тему командно-приказных авторитарных решений руководителя. Поэтому я спрошу: “Как убедить такого руководителя выслушать и учесть мнение остальных членов команды?”

P.S. Есть интересная ситуация, которую вы хотели бы разобрать? Присылайте ее на info@happy-pm.com и получите советы ваших коллег и разбор ситуации от happy-pm.com!

Интересные события в ближайшее время

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

1 октября, Санкт-Петербург. Окружной Инновационный Ковент. в рамках III Петербургского международного инновационного форума в 7-ом павильоне выставочного комплекса «ЛенЭкспо».

Основная задача Конвента – предоставить его участникам инструменты для реализации инновационных проектов. Это и возможность продемонстрировать свои изобретения и новаторские прорывы широкой общественности, и встречи с бизнесменами мирового масштаба, и лекции крупных венчурных инвесторов, и знакомство с руководством нашего города и, конечно, экспертиза проектов и возможность попасть на финал Зворыкинской Премии в Москве, где победителям её вручит лично Президент России!

подробнее о мероприятии >>

12-15 октября, Москва. Конференция CEE-SECR. Опубликована программа шестой ежегодной конференции “Разработка ПО 2010″, которая состоится в Москве с 13 по 15 октября 2010 года. К уже привычным Ключевым, Приглашенным и Обычным (устным) в этом году добавились новые, Специальные доклады от компаний и организаций - партнеров конференции, в т.ч. от CMU Software Engineering Institute, European Software Institute и др.

Традиционно, во время конференции пройдет несколько круглых столов и семинаров. В рамках конференции запланировано около 100 событий: 88 докладов, 4 круглых стола, 7 семинаров.

подробнее о мероприятии >>

12-14 ноября, Екатеринбург. CSEDays, Application 2010. Встреча студентов, аспирантов и IT-специалистов из разных городов России. Участники – те, кто занимается программированием, в университете или профессионально, и интересуется вопросами надежности программного обеспечения.

Кандидатам на участие в школе нужно пройти конкурсный отбор, при этом оргкомитет будет ориентироваться не только на заявку, но и на участие в проекте DOM API Testing. Работа над данным проектом не является обязательной, но существенно повышает ваши шансы на получение спонсорского гранта на участие в школе.

подробнее о мероприятии >>

17-18 ноября, Санкт-Петербург. Тренинг Майкла Болтона “Rapid Software Testing”, разработанный им совместно с Джеймсом Бахом.

Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software и ведёт замечательный блог о тестировании http://www.developsense.com/blog.shtml.

подробнее о мероприятии >>

Кейс “Уйти нельзя остаться”

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Один из читателей, попросивший не называть своего имени, прислал вот такой кейс из реальной жизни.

Кейс “Уйти нельзя остаться”

Много лет назад три студента (Иван, Павел, Анатолий) начали свой маленький бизнес по разработке программного обеспечения. Так получилось, что заказов было много. Причем заказы поставляли очень хорошие знакомые, и организацией продаж в компании никто не занимался (и управлением тоже). Конечно низкая цена тоже играла свою роль, но благодаря подобным заказам компания из трех человек развилась в компанию из 12 человек.

К этому времени три друга (к тому моменту они стали друзьями) как раз закончили ВУЗ и им захотелось получать более высокие доходы. Но старые заказчики много платить не могли (или не хотели), а новых заказчиков не было. Потому один из друзей (Анатолий) ушел работать в банковскую сферу, а два оставшихся стали думать что делать дальше.

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

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

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

И вот у Ивана стал выбор:

  1. Остаться в компании на должности ведущего технического специалиста. При том что технический опыт Ивана очень сильно пострадал за прошлые три года.
  2. Уйти в другую компанию и “кинуть” своих друзей. Но опять же кому нужны ведущие технические специалисты без нормального опыта работы.

На момент принятия решения в компании трудилось 15 человек, причем 5 студентов последних курсов. Средняя зарплата в компании равнялась средней зарплате по городу. Стиль управления Ивана был сосредоточен на создании “семейной” компании, где руководитель всегда выслушает и поможет советом сотруднику (причем не только в рабочих ситуациях). То есть люди в компании были привязаны к харизме Ивана.

Вопрос: что делать Ивану и как поступить оставшимся друзьям в данной ситуации?

Кто хочет поработать с Сергеем Архипенковым?

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Вероятно, читатели сайта happy-pm.com уже хорошо знакомы с Сергеем Архипенковым - ведущим российским экспертом по управлению программными проектами, основателем и идеологом Гильдии менеджеров программных проектов. Если кто-то не знаком, то он может:

Буквально только что Сергей сообщил мне, что в компании R-Style, где он работает, создается отдел заказных разработок. Руководить отделом будет сам Сергей. И ему срочно нужны хорошие люди. А это значит, появилась уникальная возможность поработать с Сергеем вживую и получить ценный опыт от большого эксперта.

Сами вакансии - чуть ниже. Не упустите свой шанс. :)

J2EE-разработка:

  • программист,
  • старший программист,
  • ведущий программист,
  • руководитель группы.

Разработка БД Oracle:

  • программист,
  • старший программист,
  • ведущий программист.

ТРЕБОВАНИЯ К JAVA-ПРОГРАММИСТАМ

Основные требования:

  • высшее образование
  • Core Java , J2EE, web service
  • SQL,  PL / SQL – базовые знания
  • Unix, Linux, и Windows NT/X

Опыт работы со следующими продуктами Oracle будет плюсом:

JDeveloper, ADF, WebLogic, ESB, BPM/BPA Suite, UCM.

Функциональные обязанности:

  • участие в проектировании и разработке трехзвенных бизнес-решений на базе Java-технологий и технологической платформы Oracle.

ТРЕБОВАНИЯ К РАЗРАБОТЧИКАМ БД ORACLE

Основные требования:

  • высшее образование
  • SQL, PL/SQL - глубокие знания
  • Знание технологических аспектов БД Oracle
  • Моделирование данных
  • Unix, Linux, и Windows NT/X

Функциональные обязанности:

  • участие в проектировании и разработке объектов БД Oracle

Условия:

  • полный рабочий день
  • соблюдение ТК РФ
  • зарплата по результатам собеседования
  • профессиональное обучение и развитие
  • месторасположение – Москва, СВАО (м. Бибирево)

Контакты

sergey@arkhipenkov.ru

Найм, мотивация и удержание программистов - вебинар Виктории Придатко, 28 октября

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

28 октября 2009 на просторах Интернета пройдет мастер-класс Виктории Придатко по найму, мотивации и удержанию программистов. Вебинар платный, но есть несколько причин туда пойти:

1. Вика действительно классный специалист. Это именно она руководила HR департаментом компании Global Logic (да-да, это там, где пиво и кальяны для программистов :) ).

2. Вика сейчас занимается практическим консалтингом по позитивному управлению персоналом - тому, чего не хватает многим нашим компаниям.

3. Вика большой друг проекта Happy-PM.com, и даже выступала на нашем киевском тренинге в апреле 2009.

Программа вебинара:

Основные моменты найма

Где и как  искать программистов?
Атмосфера интервью. Как создать собеседование-праздник!

Обстановка
Настроение
Презентация компании
Стиль разговора
Важные вопросы собеседования

1. Что важно выяснить?
a. ценности
b. умение взаимодействовать
c. мотивацию
d. интересы и увлечения</p>

2. Каких людей надо брать?
3. Что и  КАК важно говорить программисту?
4. Почему ценности и личные качества важнее всего?
5. «Продажа компании». «Как продать лед в Антарктиду»? :)
6. Что фиксировать во время интервью?
7. Как разводить на правду :)?

Оценка кандидата (доверяйте интуиции)

1. Открытые и выкупающие вопросы
2. Тест «Черный квадрат» .Оценка знаний и адекватности.
Что важно взять? Основные области оценки кандитата:

1. Мотивация
2. Ценности
3. Взаимодействие
4. Развитие
5. Удобные радости
Что важно дать? Какая информация нужна кандидату для принятия решения?

Удержание (варианты)
Опросник удовлетворенности
Методы удержания
Отношение
План развития и обучение
Выполнение обещаний

Возможность работать в глобальной команде и  еще……
Адаптация

Как адаптировать нежных и удивительных?
Особенности адаптации программистов :)
Мотивация\демотивация
MUST HAVE
MUST DIE
Программа поощрения
Частота
Классификация
Принципы поощрения

Привлечение ушедших сотрудников

Как заманить сотрудника обратно?

Статистика текучести сотрудников

Зачем нужна и что дает?

Спот (точечные) \экзит (при увольнении) интервью.

Что это?
Чем полезны?
Стиль проведения

Обучение и развитие
Варианты обучения айтишников
Стоимость вебинара:
При оплате до 20 октября оплата 80 у.е. (667 грн./2400 рубл.).
Оплата после 20 октября 100 у.е. (840 грн./2983 рубл.).
28 октября, среда
Время UKR: 11-00-15-00, перерыв 12-30-13-30
Время MSK: 12-00-16-00, перерыв 13-30-14-30

«Первый Международный Портал Вебинаров».
http://webinary.com.ua
Skype: katerinaps
Моб.: +38 (068) 440 80 88

Московские тестировщики учатся у Алексея Баранцева

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Если вы работаете в Москве, и у вас в подчинении есть один или несколько тестировщиков, то вот где их смогут научить разным толковым вещам. Алексей Баранцев, автор и ведущий беспрецендентной серии обучающих вебинаров по тестированию на этот раз  проводит два живых тренинга:

В отличие от семинаров, тренинг – это активная форма обучения, нацеленная на формирование или закрепление у слушателей определённых практических навыков. Информация передаётся в ограниченном количестве, достаточном для усвоения навыков. Преподаватель рассказывает относительно мало, в основном используются активные методы, индивидуальная, групповая и коллективная работа.

Тестирование методом свободного поиска (exploratory testing)

ПРОГРАММА ТРЕНИНГА

  1. Различные парадигмы тестирования — почему они существуют и каковы практические последствия этого.
  2. Метафора “The touring test”. Построение карты приложения. Выбор “туров”.
  3. Концепция “сеанса тестирования”. Первый практический сеанс и разбор полётов.
  4. Парное тестирование. Второй практический сеанс.
  5. Метод “шести шляп” де Боно. Третий практический сеанс.
  6. Регрессионное тестирование методом свободного поиска. Четвёртый практический сеанс.
  7. Автоматизация и тестирование методом свободного поиска — друзья или враги? Пятый практический сеанс.
  8. Особенности взаимоотношения с коллегами и начальством — как им объяснить, “чем это вы тут занимаетесь”?

Автоматизация функционального тестирования веб-приложений: Selenium + Selenium RС

ОБЯЗАТЕЛЬНЫЕ ТРЕБОВАНИЯ К УЧАСТНИКАМ:

  • общее представление об устройстве веб-приложений,
  • умение программировать на каком-либо языке программирования из следующего списка: Java, .Net (любой из языков семейства), Python, Ruby (примечание: тренер будет использовать язык Java),

РЕКОМЕНДОВАННЫЕ ТРЕБОВАНИЯ К УЧАСТНИКАМ:

  • представление о работе браузера (DOM, CSS, JavaScript),
  • знание основ XPath
  • владение фреймворком автоматизации запуска тестов TestNG

ПРОГРАММА ТРЕНИНГА

  1. Как устроен Selenium (Core, RC, Grid). В чём отличие от других аналогичных фреймворков.
  2. Selenum IDE. Простейшие тесты. Запись и воспроизведение тестовых скриптов. Отладка и доработка тестовых скриптов в среде Selenium IDE.
  3. Переход к Selenium RC. Перенос тестовых скриптов из Selenium IDE в Selenium RC. Запуск, отладка и доработка тестовых скриптов.
  4. *Основы разработки тестов с использованием TestNG.
  5. Принципы организации тестового набора. Повторное использование фрагментов кода. Многослойная архитектура тестов. Повышение устойчивости тестов к изменениям требований и реализации.
  6. Принципы создания устойчивых локаторов.
  7. *Вспомогательные инструменты — Firebug, XPather, IE Developer Toolbar.
  8. Использование различных браузеров и особенности взаимодействия Selenium с ними.

Условия участия

Стоимость участия в одном тренинге 4500 рублей.

Для тех, кто оплатит тренинг за три недели до тренинга скидка 20%.

Бонусы!!!
Каждый участник тренинга получит БЕСПЛАТНО записи трех любых онлайн-семинаров серии “Онлайн-семинары по четвергам”.

Чтобы записаться на тренинг, необходимо написать письмо по адресу trainings@software-testing.ru , в письме укажите ФИО и название тренинга. Будем рады видеть вас среди участников!!!

Кейсы по пятницам. Кейс “От %опы до успеха”.

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Один из слушателей прислал интересный кейс с вопросом, что бы я стал делать в такой ситуации (описание ситуации чуть ниже). И тут я подумал, а не сделать ли нам еженедельное обсуждение кейсов? (Тем более, что так получилось, что первый кейс про OOO reminder вызвал бурные обсуждения.)

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

Тем, кто будет участвовать активнее всех, к концу года сделаем какой-нибудь супер-мега-приз. :)

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

Итак, сегодня первый кейс, который я назвал “От %опы до успеха”.

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

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

  1. Объем работы сократится  на треть.
  2. Объем  работы останется  прежним.
  3. Объем  работы вырастет в полтора раза.

Изменения объема скорее всего приведут к соответствующим колебаниям бюджета (а значит и численности).

Рынка труда для  сотрудников данного профиля нет. Аналогичные компании вовсю сокращают персонал.

Вопрос: Каким образом Вы будет готовить сотрудников к этим новостям (если будете, конечно) ?

P.S. На фотографии - Кристофер Лэнгделл, пионер обучения при помощи кейс метода.

Как учат программистов в институтах (часть 2)

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

На прошлой неделе мы говорили о том, как учат программистов в институтах. Разгорелось оживленное обсуждение, в котором я все еще принимаю участие. :) Я обещал написать про то, что в ВУЗах хорошего и что предлагаю делать, но сегодня поступим по-другому - уйдем немного вглубь. И вот почему.

На днях я встретился с одним человеком из системы высшего образования, проректором одного из питерских ВУЗов. И прямо, значит, его спросил: как устроена система нашего высшего образования? Вкратце пересказываю ответ (наверняка что-нибудь перевру, знающие люди меня поправят).

Условно говоря, есть некое “Производство”. Что это такое не вполне понятно, но судя по всему, какие-то представители реальной производственной жизни. Они формируют требования к профессии. Эти требования уходят в Министерство образования, где к требованиям производства привязывают курсы, программы курсов, критерии проверки и все такое прочее. Далее это все спускается в институты.

В схеме есть даже механизм обратной связи. То есть компании могут послать в ВУЗ фидбэк. Типа “плохо вот вы учите программиста алгоритмам”. В мин. образования фидбэк рассматривают, программы курсов корректируют.

Во всей этой схеме, в том как она ложится на реальную жизнь, смущает несколько моментов:

1. Не вполне понятно, что такое Производство, применительно к нашей индустрии. Что это за компании, которые выдвигают какие-то требования? Непонятно.

2. Смущает то, что выделяется отдельная профессия “программист” или там “разработчик ПО”. Все ж таки в том многообразии технологий, языков и всего прочего найти что-то общее и этому учить - понятно, что надо. Но чему учить в дополнение к общему базису? Потому что иначе получается, что выпускнику, хочешь - не хочешь, после ВУЗа надо будет существенно добирать знаний.

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

4. Студентам такиво многих ВУЗах не оставляют выбора, какие предметы они хотят прослушать. Есть требования к профессии - будь любезен, слушай. А что тебе надо практически для работы? Ну это уж как-нибудь сам… (Вот в ВШЭ есть какой-то выбор. А у нас в ИТМО не было.)

5. Качество образования напрямую зависит от качества преподавателей. Что и подтверждают результаты опроса. В комментариях к первому посту отчетливо сквозит, что хороший преподаватель - сейчас скорее исключение, чем правило.

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

7. Контроль за успеваемостью по сути является профанацией. Никто не выгонит студента на 4-м курсе за то, что он не знает компиляторы. А если вдруг преподаватель начнет косить студентов направо и налево, то его вызовет к себе декан и промотивирует в грубой форме больше так не делать.

8. Институты должны заниматься научной работой - это требование мин. образования. Определенный процент преподавателей должен быть кандидатами и докторами наук. Студентам же на 90% научная деятельность в области программирования не нужна для успешного трудоустройства и последующего процветания. Им нужна практика. Соответственно, преподавать ее должны практики, а не ученые.

Это все непонятные моменты, которые очень смущают. Прежде всего менеджеров, которые потом набирают к себе на работу студентов. :) Я прекрасно помню эти наборы. Разброс по знаниям, навыкам, желанию и пр. у одногруппников может быть диаметральным. Значит, система, на мой взгляд, не работает так, как могла бы.

На этом я думаю, что критику надо закончить, а постом на следующей неделе уже подумать, что со всем этим можно сделать.

Признак кризиса в компании

На пятничном мероприятии студенты естественно спросили про признак неудачного проекта/компании. (Ну чтобы понять, куда идти, куда не идти). Менеджеры сошлись на том, что высокая текучка - самый главный признак. True.


С Ромой договорились сделать интервью. Скоро будет.