Как стать автором
Обновить

Два мира или “инженерам есть, что сказать”. О различных типах сложных задач и процессах связанных с ними

Время на прочтение 4 мин
Количество просмотров 9.3K
Всего голосов 26: ↑24 и ↓2 +22
Комментарии 22

Комментарии 22

нельзя судить человека за то, что он не смог решить задачу.

Конечно нельзя за это судить. Судить нужно за то, что человек не хочет найти способ (научиться, узнать ...) решения задачи.

НЛО прилетело и опубликовало эту надпись здесь

Т.е. боремся с Обломовщиной.

Мне кажется, хороший менеджер тоже должен уметь решать difficult задачи. В конце концов, на самом высоком уровне задача коммерческой компании в конкурентной среде тоже difficult — «заработать денег».


Задача менеджеров — перевести эту difficult задачу в инженерные difficult задачи. Чем меньше менеджер способен комфортно работать с этими двумя неопределенностями, тем больше он пытается на своём уровне разбить все на компоненты и процедуры, выстроить дисциплину и жёсткие процессы. Удаётся не всегда.


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

Уверен что хорошему менеджеру нужно уметь решать difficult задачи тоже. Но что делать если не дано? Или должен быть еще один «менеджер» (работая сейчас в Европе, вижу что часто эту функцию выполяют архитекторы) или нужно уметь доверять и общаться с инженерами.
НЛО прилетело и опубликовало эту надпись здесь
Хороший комментарий :). Да, такое ощущение что в MBA (судя по тем с кем я общался) учат прежде всего хорошему тайм менеджменту, но в том то и штука что в случае исследований это плохо работает. Должны быть другие процессы, другая атмосфера,…
Еще раз хочу сказать что это не значит что про время и деньги думать не надо. Конечно на уровне менеджмента это главная задача, но в мир инжеров это должно спускаться в другом виде.
НЛО прилетело и опубликовало эту надпись здесь

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


Из этого не следует, что сроки-трудности-результат-… не нужно пытаться прогнозировать и этим прогнозам пытаться следовать и обновлять их по пути. Из того, что задача решится непонятно как и когда, не следует, что надо обязательно уйти на год ее решать "в свободном поиске" — а следует, что надо обсуждать проблемы, менять курс по пути, и т.д., и вообще решение может быть совершенно не инженерным в итоге.


Тут много что можно понаписать, но вот нового мало что можно сказать.

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

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


Ваш текст можно при желании прочитать как "мы такие тут все нежные и уникальные в IT, все такое непредсказуемое, дайте нам бесконечные деньги и бесконечное время и не трогайте" — вот с этим я не согласен категорически.

:)
Текст не о том какие мы хорошие а другие плохие. Текст про то что нужны разные подходы к разным задачам. Так же даются методы решать difficult задачи и пожелание менеджерам ценить людей способных решать эти задачи а не смотреть на них свысока.
Этим двум важным мирам нужно уметь ладить. Это как форма и содержание — и то и то важно
— О, ты не спишь? Тут проектик есть, надо сдать с утра.
— Погрузился, ть.
Я их буду называть английскими словами complex и difficult.

На языке родных осин это «сложный» (как антоним для «элементарный») и «трудный» (то есть требующий много труда).
Просто слово сложный с русского именно так и переводится — complex/difficult.
Мы в этом слове не различаем эти нюансы. А английские термины отражают точно суть.
Но конечно термины это всего лишь термины.
Спасибо за комментарий.
Рутинная работа грузчика в таких терминах «трудная» (требуется много труда), но в смысле, о котором говорит автор статьи, она complex, а не difficult.
[оффтоп]
А чем термин «комплексная задача» хуже, чем «complex задача»?
А чем термин «сложная задача» хуже, чем «difficult задача»?
Очень неудобно читать. Постоянно «спотыкаешься» об эти слова.
[/оффтоп]

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

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

На самом деле это касается не только инженеров, это касается всех работников. Даже самых простых кладовщиков или уборщиц. Если работник замотивирован выполнять некоторую работу то он справляется с ней лучше и сильно быстрее (в 2-3 раза) чем незамотивированный работник (если что это было проверено опытным путем еще в начале 20го века).

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

deadline, complex, difficult. Зачем? Вы же инженер, а не продавец или маркетолог.

В проектах нужно. Там все переплетается.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории