http://experience.openquality.ru/elena-sagalaeva-interview/
Елена, сможете ли вы рассказать о наиболее значимой ошибке, которую вам доводилось видеть в проектах?
Самые суровые проблемы возникают из-за неверно принятых решений, не из-за того, что программист где-то плюс с минусом перепутал. И из-за попыток решить технические проблемы политическими методами. Или вот, например, ставим работать программистов, которые друг друга не знают. Не назначаем среди них главного и ждем, что они друг с другом договорятся. Они не договорятся. Это классическая запланированная катастрофа, я несколько раз такое наблюдала.
11 комментариев:
Статью почитал.
Сборник банальностей.
"Коллега что за х... нам показывают?".
Где то самое интересное?
Глубокое интервью? Где заявленная глубина, где анализ механизмов проблем?
Короче слабенько. На среднем "европейском" уровне средненького менеджера. Троечка.
Гм, коллега - глубокий анализ в интервью?
Банальности, только вот все в них вступают постоянно.
Интересно что ты про Брукса с его Месяцем скажешь?
Да. Глубокий анализ в интервью. Если человеку есть что сказать и он в теме, то и интервью хватит, чтобы наметить главное и дать ссылки на детали.
А кто такой Брукс с его месяцем? Он, что Бог? Чего это я о _своих_ проблемах должен спрашивать у него?
Проблемы и их решения существуют/появляются не в голове у бруксов, а в реальности. Так что изучаешь реальность, применяешь логику и получаешь ответы. Заметь не просто ответы, а предельно конкретные и специфичные (а значит максимально эффективные) для твоей конкретной ситуации.
Отсюда и все проблемы, все решили почему-то, что все их проблемы за них решат какие-то "ученые", "невидимая рука рынка", "демократия" и пр. математические абстракции.
Ты не должен, но можешь :)
Почему-то повторное использование алгоритмов и кода возражений не вызывает, но когда дело касается организационно-управленческих моментов - у все ситуация мегауникальная :)
Можно ждать что ты напишешь максимально конкретную и специфичную ОС для своих задач? Ведь наивно ждать что какие-то торвальдсы абстрактно и универсально решат твои потребности, так?
Во-первых, сравнивать алгоритмы и людей как минимум некорректно. Алгоритм - это просто последовательность действий, как правило абсолютно детерминированная (заранее можно с 100% точностью предсказать результат). И реализованный в программе, ты всегда знаешь что будет на выходе, когда что-то на входе. Неработающий бред типа нейронных сетей в расчет можно не брать.
Понятно, что современное гос-во, СМИ и их политика активно пытаются привести все действия человека к алгоритму.
Плюс весь объем информации поступающей на вход системе "человек" контролировать никто не в состоянии (пока, к счастью).
Так что да, я считаю, что каждая система из нескольких человек - вещь уникальная. Максимум что можно о ней сказать - это какие-то статистические закономерности. И работа с каждым элементом системы, как с черным ящиком. Это так сказать логические выводы. Если в моих рассуждениях есть ошибка, то я хочу о ней услышать.
А до тех пор, я буду считать управление искусством/наукой, в большей степени зависящим от конкретной системы и способностей конкретного управленца.
Если само повторное использование как сама идея возражение не вызывает, то его реализация в популярных языках вызывает и еще как. Например, книги по шаблонам проектирования (Фаулер и как там зовут этого деятеля, что все цитируют как тупые зомби?) в явном виде нарушают принципы повторного использования. Почему? Очень просто - просто сами языки, под которые эти шаблоны существуют, не в состоянии эффективно оформить эти шаблоны в виде библиотек! То есть вместо обучения программистам более серьезным языкам, просто разрешают им изобретать велосипед, но только для шаблонов. Все популярные/промышленные языки программирования страдают этими проблемами.
То, есть сейчас доминирует идея, что выгоднее нанять кучу дешевых программистов/индусов, дать им что-то типа Явы, и пущай они каждый раз, в каждом отдельном проекте реализуют эти шаблоны как Бог на душу положит.
Если мне будет надо и ОС напишу (пока Линукс закрывает все мои текущие и будущие задачи с лихвой). ОС Спектрума занимала 16кб вместе с интерпретатором бейсика и системой вывода-вывода.
Правильно, торвальдсы решают те задачи, которые можно решить в общем виде, см. выше. Еще раз - любое ПО - это не общество.
Да никакой ошибки, только подытожу - и в управлении людьми можно сформулировать общие подходы, которые работают. И такие подходы сформулированы, только вот многие управленцы пытаются их изобретать заново.
Касательно уникальности попробую на примере. Если в 95 случаях из 100 приход нового человека отбрасывает команду(уникальную систему) по производительности назад, то в чем уникальность _этой_ ситуации? Почему о ней нельзя прочитать зарание и запланировать доп. время?
Ппц, дорогая редакция.
Твой пример - это чего реальная проблема? И чтобы ее решить для этого надо прочитать кучу умных книг? Че-нить по-серьезнее есть?
Я надеюсь, что это пример не из твоей практики. Иначе, единственный совет, который я могу дать - бежать от таких управленцев.
Это реальная проблема, с которой многие, я в том числе, сталкиваются достаточно часто. Она простая и очевидная (ибо сформулирована еще хз когда) - как раз для обсуждения.
Но ведь таковым(простым и очевидным) ты можешь объявить любой пример, так ведь? Может ты что приведешь, из серьезного(из практики разработки ПО есесно)?
Сформулировать задачу управленца в сфере IT? Да запросто. По сути ничем от обычного производства не отличается. Особенно быдлокодирование, которым занимается 98% программистов и фирм.
Планирование ресурсов, отслеживание прогресса (или ключевых показателей, например в процентах) и разрешение производственных/политических проблем _в реальном времени_ (обратная связь). Все, больше никаких действий от управленца не требуется.
Детали реализации - это конкретные рецепты, уникальные для команды. Есть люди, которых и контролировать не надо, есть те, которые эффективно работают большими кусками по-одиночке, есть те, которые решают нестандартные уникальные задачи и т.д.
Да нет, примеры вот этих уникальных задач, которые не повторяются от команды к команде.
На мой взгляд большая часть их формализуема и имеет общее решение. Как косвенное док-во этого - успешный менеджер успешно управляет переходя от проекта к проекту, т.к. он уже наработал общий опыт который позволяет ему справляться с "уникальностями" каждой новой команды.
А, тебе конкретный пример? Да запросто.
Просто берем пример с моей текущей работы.
Имеем кодовую базу примерно 200тыс. строк на APL. Сравнения на Си будет пару миллионов. Кодовая база постоянно растет и изменяется. Плюс мы взаимодействуем с кодом остальных 20 команд размером около 10 миллионов строк на APL+C#. Наша команда из 15 человек программистов. Только 3 достаточно хорошо представляют себе чего там натворили. И то, только в области, где они специалисты. Остальным нужно некоторое время (бывает полгода только на понимание+дизайн), чтобы въехать в суть задачи, понять как втиснуть эту задачу в существующую архитектуру. Нет, не правильно, архитектуры там нет. Там есть код :). Задача упрощена тем, что исследовательской составляющей в проекте нет. Так что все проблемы имеют решения по-определению.
А теперь вопрос к твоему воображаемому универсальному управленцу - как распределить задачи между всеми программистами из запланированной стопки задач (стопка задач на десять лет вперед, и я не шучу). Сделать это надо с учетом всех сильных и слабых сторон программистов в команде и в конечное время :).
Да, и можно я добавлю еще одно условие? Раз управленец в твоем понимании такой универсальный солдат - пускай он не спускает на других (тех троих, что понимают) свою работу планирования, отслеживания прогресса и оперативного управления. Иначе, получается, что он такой универсальный управленец нах не нужен.
Разрешаю использовать любых бруксов, фаулеров и пр. деятелей, но только в пределах знаний успешного переходящего из фирмы в фирму управленца. Само собой знаний предметной области у нет и не может быть по определению.
Отправить комментарий