Не понимаю за что плюсы. Автор излагает свои поверхностные знания об асинхронном программировании, делает неверные выводы, а ведь кто-то эту статью будет использовать как учебное пособие.
Что там с threading?
Тут особо смысла нет - практический эксперимент показал, что threading показывает такие же результаты (плюс - минус), как асихнронный код из пункта 3.
multiprocessing
Не буду врать, просто посмотрел как нечто похожее делал какой-то индус с Ютуба. Результаты сильно хуже, чем у предыдущих способов. Да и писать такой код - это насилие над своей психикой. А я свою психику берегу.
Языковые конструкции async await — это просто синтаксический сахар. Значение имеет только конкретная реализация и конфигурация под капотом этих конструкций.
Автор использовал дефолтную реализацию в Python — на ивент лупе. Любые вычисления на CPU будут блокировать весь поток и съедать весь выигрыш на асинхронных операциях чтения из неблокируемых сокетов. Внезапно, к этим вычислениям относится даже json десериализация.
Поэтому если говорить о реальных RPS, которые измеряются тысячами, а не десятками, без мультипоточности или мультипроцессорности не обойтись. Ниакой asyncio.gather тут не поможет.
Может я не умею верно доносить мысли до людей, может просто стоило более тщательно выбирать команду и проект для работы. Думаю стоит отдавать внимание чутью и настоять на своём, постараться донести мысль до менеджера
Что если один из тиммейтов предложит вам быстренько влить откровенно нерабочий код в мастер? Вы сразу согласитесь на его уговоры, или аргументировано откажете и попросите внести правки?
А если в ваш код начнут коммитить ребята из соседних команд: QA, DevOps, системные администраторы? Вы согласитесь или будете разбираться с нарушителями границ вашей зоны ответственности? К менджерам в вопросах планирования работы надо относится точно так же.
К сожалению, многие думают, что менеджер представляет “власть”, имеет какой-то неоспоримый авторитет и покровительство над вами. Это не так. Менеджер — сотрудник, наравне с вами, решающий вопросы организации рабочего процесса. Даже ваш руководитель проекта, технический директор и операционный директор — не более чем сотрудники, которые решают организационные задачи, только с другим масштабом.
Чувствуйте себя уверено в обсуждении и постановке адекватных сроков для разработки качественных решений. Если такая позиция будет вызывать проблемы и конфликты с администраций компании — зачем оно вам надо, в отрасли полно других компаний, в которых такой подход точно оценят.
Вы так демонизируете менеджеров, как будто это какие-то особые люди.
Вы ведь не считаете, что разработчики святые? Среди них есть такие же ребята, которые осознано гробят проект ради собственной выгоды. Они затаскивают новые технологии и подходы в разработку только чтобы удовлетворить свой технический интерес или натренировать навыки необходимые для перехода в другую компанию, а что будет с проектом потом им не интересно.
Но в целом, я с вами не спорю. Качество работы любого сотрудника — это вопрос его мотивации.
Но посмотрите, как развит образовательный процесс у программистов. Учебные пособия любых форм и объёмов доступных для изучения: тяжелые книги, легкие статьи, интерактивные задачки, пошаговые туториалы, видосики, учебные курсы, подсказки в IDE, обсуждения на Stack Overflow в конце концов.
А как прокачивать свои компетенции руководителю? Живой практики недостаточно, нужны фундаментальные знания. Взять их неоткуда, потому что общество не создаёт запрос на реальные требования к своим руководителям. Утрирую конечно, но вы где-нибудь видели что соискатель даёт тестовую задачку по менеджменту своему потенциальному CTO/PM/тимлиду в процессе собеседования?
Вот и получается, что в лучшем случае один "менеджер" заказывает другим "менеджерам" бизнес-тренинг про успешных успех. Они там друг другу улыбаются, обнимаются, ручки продают. А то, что рабочий процесс требует системного анализа, для развития бизнеса нужно исследование и прогнозирование — всё это проходит мимо внимания потенциального руководителя.
Но ведь понравится нанимателю может специалист по продажам, или квалифицированный переговорщик. К человеку, который должен уметь управлять производственным процессом это требование не применимо.
А знаете почему так? Потому что в нашем представлении даже чел, который сидит на холодных продажах — тоже "менеджер” по продажам.
Поэтому я и пытаюсь в своих комментариях сделать акцент на том, что менеджер, то есть руководитель — это вполне конкретная специальность, с четкими обязанностями и требованиями к навыкам. А не парень, который приятен для бизнеса в общении.
Плохо когда сотрудник тащит и ни с какими проблемами не приходит к руководителю, а тот думает, что их у сотрудника нет, а не то, что сотрудник их решает без помощи. Вот таких многие руководители разглядеть не в состоянии. После повышения парочки коллег будет так: вот мое заявление.
О, это моё любимое.
Как известно деятельность человека может быть реактивной или проактивной. Первая с нами с самого рождения, вторая возможна только если подключить рациональное мышление. Мы начинаем прогнозировать будущее, и собсна производить действия, чтобы это будущее было максимально приятным.
Но, большинство людей, как в бытовой, так и профессиональной деятельности выбирает только реактивную модель. Никакой интриги, реактивность подразумевает меньший расход собственных сил, к тому же прогнозирование может быть неточным, а значит и проактивная деятельность окажется “бесполезной”.
Инженеры в массе своей подходят к работе проактивно. Поэтому так много историй про попытки придумать идеальные архитектуры, бесконечные требования предоставить исчерпывающий анализ предметной области и прочее. Инженеры хотят чтобы прогнозы были точные, действия получились максимально эффективными.
Но у руководителей не так.
Начальник не должен знать все, но при возникновении проблем должен сам погрузиться до нужной степени и понять кого еще подключить для решения.
Почему-то считается в порядке вещей, что руководитель буквально царь — сидит и ждет у себя в кабинете, когда ему принесут конкретную проблему и несколько вариантов её решения, чтобы, выбрав один из них проявить свою великую мудрость и законные полномочия.
Поймите, что если вы как руководитель, начнёте действовать проактивно: начнёте анализировать ситуацию, прогнозировать, развивать экспертизу на будущее. То не потеряете много сил и нервов, наоборот сэкономите — сделаете и себе и сотрудникам будущее без проблем. Не придется потом с удивлением для себя ловить заявления на увольнение, нерабочие архитектуры и запоротые сроки.
Конечно, разработчики могут ошибаться из-за своей неопытности либо скудоумия. Однако, часто в больших компаниях то, что мы воспринимаем как ошибку разработчика, происходит помимо его воли. Изменчивая внешняя среда диктует свои условия.
Ох уж эта враждебная внешняя среда, невидимая сила, череда недетерминированных событий о которых никто ничего не знает и не может сделать.
Не бывает неверных решений как и ошибок происходящих мимо воли автора, особенно у опытных разработчиков. Бывает неверно понятая мотивация автора, неполная постановка задачи, плохие условия труда, отсутствие подготовки:
Описал вычисления некорректно? Торопили, согласился сделать без тестов.
Не учёл негативный сценарий? Думаю только о позитивном, аналитика нет.
Не использовал сахар? Делаю как привык за последние пять лет.
Написал откровенно нерабочий код? Не знаю как написать рабочий.
Решение не полное? Тороплюсь к другу на день рождения.
К сожалению, наша жизнь — это компромисс между нашими желаниями и нашими возможностями.
К счастью, наша жизнь — это бесконечный пример того, как мы боремся с внешней средой, расширяя свои возможности для достижения желаний.
Поэтому с общим настроением вашей статьи я не согласен. На мой взгляд, неправильно воспринимать проблемы как данность и ждать для их решения появление волшебной “золотой шестерёнки” — к проблемам стоит подходить аналитически и системно.
В любом случае спасибо за статью, будет интересно почитать вторую часть.
Если все обозначенные стороны у такого человека развиты, то назовём его «золотой шестерёнкой», а цену за это назовём в конце статьи.
В статусе так называемые «золотые шестерёнки» находятся чуть выше мужиков ну и соответственно знают о разработке чуть больше. Также довольно-таки важный фактор состоит в том, что «золотые шестерёнки» имеют благосклонность авторитетов руководителей что даёт им не мало привилегий. Сами себя они никогда не назовут «золотыми шестерёнками» (так как это звучит довольно обидно) а называют они себя обычно «создающими движение бизнеса» или «ведущими».
Согласен с вами, некомпетентность руководителя — насущная проблем. Но в чём польза таких историй из жизни? Просто в очередной раз побухтеть в комментариях, выпустить пар?
Поделитесь лучше своими соображениями как эту компетентность развивать, что предпринять сотрудникам, на ваш взгляд, во избежание демотивации или помощи своему руководителю.
Но тогда мне не совсем понятно как можно, например, за восемь лет не повысить свой уровень экспертности?
Мне жалко времени сидеть и делать линейные задачи. Мне с них опыт не капает. Время утекает слишком быстро, я это чувствую. Поэтому суечусь как-то, хочется сделать больше, использовать свой ресурс эффективнее.
А вот на одном проекте со мной работал молодой специалист, он сказал что ему нравится "не пыльно" клепать тестики по шаблону.
Могу на это ответить только рассуждениями из собственной опыта.
Увлекаюсь программированием независимо от того, приносит это деньги или нет. Работаю над собственными проектами и на выходных, и параллельно основной работе.
Раньше удивлялся, почему многие люди вокруг не вкладываются в изучение технических дисциплин, с такой же упоротостью, как и я, ведь это так интересно и перспективно!
А потом как-то резко осознал, что у этих людей кроме экспертности в своей профессии есть много чего, что для меня недостижимо: семья и дети, опыт восхождения на горы, навыки в оперном пении, собственная группа по игре D&D. Всё сразу стало на свои места, и как-то полегчало.
На заре индустрия состояла исключительно из экспертов и научных деятелей, целиком увлеченных компьютерами. Но сейчас это обычная работа, не нужно удивляться что многие умеют делать тоже что и вы и получить за это деньги без каких-либо романтических и героических замыслов. Лучше поинтересуйтесь чем они таким интересным занимаются вне рабочего времени.
И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно.
Знаете почему расстреливали? Потому что акт насилия происходит от бессилия, это крайняя мера, к которой прибегают когда все другие известные способы решения проблемы не получается осуществить.
Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела.
Так умеют, что в советское время создавали целые направления и кружки для изучения и решения проблем менеджмента на производстве. Это всё с тех времен тянется. Познакомьтесь, например, с Щедровицким. Из его лекций можно узнать, что руководители и начальники бюро в принципе не понимали, как строить заводы и управлять производственными процессами в срок.
И что-то мне подсказывает, отсутствие обратной связи и исключение исполнителей из планирования — было одной из причин этих проблем.
А каким образом, по-вашему, руководитель группы планирует корректный срок для решения задачи?
На мой взгляд, он не может быть экспертом и практиком в той области, которой занимается исполнитель. Поэтому грамотный срок определить он может только на основе показаний исполнителя:
Сделаю за 1 день, но плохо
Сделаю за 2 дня, но потом придётся переделать за 4 дня
Сделаю за 5 дней, но хорошо
Не сделаю, вы требуете невозможного
Поэтому, грамотно обработать спущенный срок в зоне ответственности исполнителя. Я не говорю, что только он за него отвечает, но тоже отвечает, да.
Другое дело, если руководитель игнорирует комментарии и варианты сроков исполнения — это уже неадекватность. В таких случаях свою зону ответственности желательно переводить в другую компанию.
Обиделись все на то, что вы пренебрежительно отозвались о линейных разработчика, как будто бы всех их назвали бестолковыми.
После вашей разъяснений я бы сказал, что это не "линейность", а "экспертность". Ну и называть людей экспертами, всегда приятнее.
Насчет широты взглядов. Рекомендую вам ознакомится с тем, как люди понимают сам процесс изобретений и научного прогресса (например, есть история про изобретение фотоаппарата). Похоже всё сводится к тому, что изобрести новое из ничего невозможно. Новые изобретения — наблюдение и совмещение удачных идей из разных сфер деятельности, порой самых неожиданных.
В этом плане мнение даже самого узконаправленного специалиста иногда помогает сделать лучше решение инженера самых широких взглядов.
Ситуация: заказчик недоволен. Ваша компания - подрядчик, по каким-то причинам что-то не успевает. Вашему менеджеру на последнем созвоне ох как досталось, но он защитил "ментальное здоровье" команды от негатива, впитал посыл ...
Хорошо, давайте попробуем конструктивно ситуацию разобрать. По-вашему, кто отвечает за срыв сроков? Кто не провёл достаточный анализ и подписал подрядчика на кабальные сроки? Кто решил, что единственное эффективное средство вести дела — это лояльно принимать всё, что спускают топы заказчика? Кто не разобрал причины неуспевания — то есть не учел риски подряда?
На мой взгляд, менеджер — не секретарь, чтобы передавать поручения, и не будильник, чтобы напоминать о задачах в Jira, и даже не стенографист, который записывает за другими meeting notes.
Менеджер — сотрудник, который организует, руководит и управляет рабочим процессом.
Так что невыполнение сроков полностью в зоне ответственности менеджера. Даже если у вас команда ленивых саботажников и вы физически не могли в срок реализовать задуманное. Всё равно это ваша проблема, как менеджера — вы не разобрались какая производительность у вашей команды, не нашли квалифицированных исполнителей, не подстраховали риски дополнительным ресурсом.
Пусть за косяк команды страдает на созвонах менеджер или кто угодно, но не исполнители?
И да, вполне естественно, что в случае своих профессиональных ошибок менеджер при этом как человек тоже страдает и спрессует. Уверен, что любая классная команда в этот момент поддержит своего менеджера.
Но драматизировать управленческие провалы и представлять менеджера как героя не нужно. Это его ошибка, он должен её проанализировать, исправить и предотвратить в будущем, а не устраивать конфликты внутри команды.
Мне кажется, вам бы понравилось в средние века. Там многие считали, что «знание» в принципе от сатаны, засоряет не только разум, но и душу. А вот вера в кресты — единственное спасение.
Условно говоря, regex помочь написать может любой, а подсказать как лучше сделать какую-то сложносоставную систему, типа фреймворка - нет. С инженером можно говорить практически на любые айтишные темы, с линейным разработчиком - скорее выборочно.
Сложносоставную систему, типа фреймворка вы для кого делаете? Для инженеров или линейных разработчиков?
Вы зря недооцениваете пользу от общения с "линейными разработчикам". Даже если под этой категорией вы имеете ввиду неопытных разработчиков.
Нет ничего лучше, чем комментарий или мнение разработчика, который не хочет или не понимает "сложносоставную систему". Это всегда спасает от перегиба в дремучие, понятные и полезные только лично вам, аспекты космолётостроения.
Дело в том, что PM в ходе своей работы сталкивается не с управляемым кодом или красивыми рисунками, а с самым непредсказуемым в природе материалом - людской психикой. Только держа в голове разнообразные хитрости, слабости и приемы уклонения, мы можем если не избежать, но уменьшить фактор риска при срыве тех или иных сроков.
Ну да, у программистов послушный компьютер, а у дизайнеров и иллюстраторов красивые картинки. И только у менеджеров другое — у них сложная, непохожая ни на что работа.
Есть целая категория науки, которая занимается проблемами менеджмента — это гуманитарная наука. В неё входит большое количество учебных материалов и исследований по вопросам решения менеджерских задач. Кстати, хитрости, уклонения и манипуляции сотрудниками — не входят в перечень инструментов для решения этих задач.
Только не воспринимайте мои комментарии как нападки.
Мы тут сотни статей пишем о требованиях к навыкам программиста: теория, алгоритмы, разбирайся в бизнесе, умей в софты, организуй свой рабочий процесс, оценки давай для задач.
А для менеджера у нас какие требования? Лояльность, интуиция, пару лайфхаков управления из паблика про менеджмент. Я считаю, что мы должны развеять миф о том, что на менеджера не нужно учится.
Срок, спущенный сверху, НИКОГДА не является зоной ответственности исполнителя
Срок, спущенный сверху, всегда является зоной ответственности исполнителя. Потому что это один из факторов принятия решения. Например, программист может применить готовый проблемный алгоритм, если бизнесу надо завтра, или придумать новый качественный за месяц, если сроки квартальные.
Также зоной ответственности исполнителя является способность дать аргументированный отказ, если сроки неадекватные.
Как же всё-таки правильно ставить и соблюдать сроки?
Ответ на этот вопрос уже давно дан в книге "Мифический человеко-месяц". Достаточно осознать, что есть два вида сложности задачи: практическая и концептуальная.
Первая подразумевает что решение уже известно, нужно только его исполнить. Это любая работа, для которой уже есть алгоритм или императивная инструкция. Такие работы можно оценить с точностью 100%, их легко автоматизировать, включить в инструментарий.
Вторая подразумевает что решения не существует, его нужно найти. Оценить такие задачи невозможно никакими способами. Потому что оценивать можно только то, что известно. Это, например, новые бизнес фичи, архитектура сервиса или алгоритм обработки данных.
Любую задачу концептуальной сложности можно превратить в задачи практической сложности. Для этого необходимо проводить исследования.
Например. Прежде чем брать новую фичу в спринт, сначала провести системный и бизнес-анализ за фиксированное время. Если задача слишком сложная, этот анализ проводится несколько раз, пока всё же не будет найдено решение. И только потом это решение, декомпозированное на практические задачи, берётся в работу.
Кстати, проводить анализ можно итерациями и по 2 дня, и по 2 часа, смотря к какому темпу готова компания и команда. Так что популярный аргумент “нам некогда, нам бизнес делать надо” не работает.
Если проектный менеджер или тимлид этого не понимает, толкает в работу концептуальные задачи без исследования - никакие средства контроля и самообмана не помогут (кроме везения), сроки будут нарушены.
По-настоящему гениальный творец должен быть нищим, а его труд не ради прибыли. Это распространённое у нас представление о творчестве. Наверно, потому что звучит благородно.
На самом деле стремление получить прибыль, во многом есть стремление обрести независимость, чтобы увеличить масштаб своих возможностей. Нет ничего плохого в том, что компания выпускает игру ради прибыли.
Проблема в другом. Тот продукт, который сейчас подаётся в маинстриме под названием “игры”, называется так только из-за скудности языка:
Азартные сделки, которые вызывают привыкание
Мультимедийные проекты, стремящиеся встроится в денежный поток рынка
Мошеннические схемы для обмана
Площадки для распространения рекламы
Всё это в обёртке “игр” пытаются втюхать потребителю. Он возмущается, но всё равно потребляет, потому что сориентироваться сложно.
Вот вам простая аналогия. Люди уже десятилетиями потребляют БАДы, и некоторые, так и не поняли, что это не настоящие лекарства, и толку от них не больше, чем от свежего огурца. Хотя коробочки красивые, и выглядят как таблетки.
Так же и в игровой индустрии, современные “медийно активные добавки” являются по сути чем угодно, но не играми. Не нужно удивляться что в очередном продукте компании, которая разработчиком игр является только номинально, с вас пытаются выкачать максимум денег, а не увлечь новым опытом через игровой процесс.
Не понимаю за что плюсы. Автор излагает свои поверхностные знания об асинхронном программировании, делает неверные выводы, а ведь кто-то эту статью будет использовать как учебное пособие.
Языковые конструкции async await — это просто синтаксический сахар. Значение имеет только конкретная реализация и конфигурация под капотом этих конструкций.
Автор использовал дефолтную реализацию в Python — на ивент лупе. Любые вычисления на CPU будут блокировать весь поток и съедать весь выигрыш на асинхронных операциях чтения из неблокируемых сокетов. Внезапно, к этим вычислениям относится даже json десериализация.
Поэтому если говорить о реальных RPS, которые измеряются тысячами, а не десятками, без мультипоточности или мультипроцессорности не обойтись. Ниакой asyncio.gather тут не поможет.
Что если один из тиммейтов предложит вам быстренько влить откровенно нерабочий код в мастер? Вы сразу согласитесь на его уговоры, или аргументировано откажете и попросите внести правки?
А если в ваш код начнут коммитить ребята из соседних команд: QA, DevOps, системные администраторы? Вы согласитесь или будете разбираться с нарушителями границ вашей зоны ответственности? К менджерам в вопросах планирования работы надо относится точно так же.
К сожалению, многие думают, что менеджер представляет “власть”, имеет какой-то неоспоримый авторитет и покровительство над вами. Это не так. Менеджер — сотрудник, наравне с вами, решающий вопросы организации рабочего процесса. Даже ваш руководитель проекта, технический директор и операционный директор — не более чем сотрудники, которые решают организационные задачи, только с другим масштабом.
Чувствуйте себя уверено в обсуждении и постановке адекватных сроков для разработки качественных решений. Если такая позиция будет вызывать проблемы и конфликты с администраций компании — зачем оно вам надо, в отрасли полно других компаний, в которых такой подход точно оценят.
Вы так демонизируете менеджеров, как будто это какие-то особые люди.
Вы ведь не считаете, что разработчики святые? Среди них есть такие же ребята, которые осознано гробят проект ради собственной выгоды. Они затаскивают новые технологии и подходы в разработку только чтобы удовлетворить свой технический интерес или натренировать навыки необходимые для перехода в другую компанию, а что будет с проектом потом им не интересно.
Но в целом, я с вами не спорю. Качество работы любого сотрудника — это вопрос его мотивации.
Согласен с вами, всё зависит от человека.
Но посмотрите, как развит образовательный процесс у программистов. Учебные пособия любых форм и объёмов доступных для изучения: тяжелые книги, легкие статьи, интерактивные задачки, пошаговые туториалы, видосики, учебные курсы, подсказки в IDE, обсуждения на Stack Overflow в конце концов.
А как прокачивать свои компетенции руководителю? Живой практики недостаточно, нужны фундаментальные знания. Взять их неоткуда, потому что общество не создаёт запрос на реальные требования к своим руководителям. Утрирую конечно, но вы где-нибудь видели что соискатель даёт тестовую задачку по менеджменту своему потенциальному CTO/PM/тимлиду в процессе собеседования?
Вот и получается, что в лучшем случае один "менеджер" заказывает другим "менеджерам" бизнес-тренинг про успешных успех. Они там друг другу улыбаются, обнимаются, ручки продают. А то, что рабочий процесс требует системного анализа, для развития бизнеса нужно исследование и прогнозирование — всё это проходит мимо внимания потенциального руководителя.
Да, интересный момент вы затронули.
Но ведь понравится нанимателю может специалист по продажам, или квалифицированный переговорщик. К человеку, который должен уметь управлять производственным процессом это требование не применимо.
А знаете почему так? Потому что в нашем представлении даже чел, который сидит на холодных продажах — тоже "менеджер” по продажам.
Поэтому я и пытаюсь в своих комментариях сделать акцент на том, что менеджер, то есть руководитель — это вполне конкретная специальность, с четкими обязанностями и требованиями к навыкам. А не парень, который приятен для бизнеса в общении.
О, это моё любимое.
Как известно деятельность человека может быть реактивной или проактивной. Первая с нами с самого рождения, вторая возможна только если подключить рациональное мышление. Мы начинаем прогнозировать будущее, и собсна производить действия, чтобы это будущее было максимально приятным.
Но, большинство людей, как в бытовой, так и профессиональной деятельности выбирает только реактивную модель. Никакой интриги, реактивность подразумевает меньший расход собственных сил, к тому же прогнозирование может быть неточным, а значит и проактивная деятельность окажется “бесполезной”.
Инженеры в массе своей подходят к работе проактивно. Поэтому так много историй про попытки придумать идеальные архитектуры, бесконечные требования предоставить исчерпывающий анализ предметной области и прочее. Инженеры хотят чтобы прогнозы были точные, действия получились максимально эффективными.
Но у руководителей не так.
Почему-то считается в порядке вещей, что руководитель буквально царь — сидит и ждет у себя в кабинете, когда ему принесут конкретную проблему и несколько вариантов её решения, чтобы, выбрав один из них проявить свою великую мудрость и законные полномочия.
Поймите, что если вы как руководитель, начнёте действовать проактивно: начнёте анализировать ситуацию, прогнозировать, развивать экспертизу на будущее. То не потеряете много сил и нервов, наоборот сэкономите — сделаете и себе и сотрудникам будущее без проблем. Не придется потом с удивлением для себя ловить заявления на увольнение, нерабочие архитектуры и запоротые сроки.
Ох уж эта враждебная внешняя среда, невидимая сила, череда недетерминированных событий о которых никто ничего не знает и не может сделать.
Не бывает неверных решений как и ошибок происходящих мимо воли автора, особенно у опытных разработчиков. Бывает неверно понятая мотивация автора, неполная постановка задачи, плохие условия труда, отсутствие подготовки:
Описал вычисления некорректно? Торопили, согласился сделать без тестов.
Не учёл негативный сценарий? Думаю только о позитивном, аналитика нет.
Не использовал сахар? Делаю как привык за последние пять лет.
Написал откровенно нерабочий код? Не знаю как написать рабочий.
Решение не полное? Тороплюсь к другу на день рождения.
К счастью, наша жизнь — это бесконечный пример того, как мы боремся с внешней средой, расширяя свои возможности для достижения желаний.
Поэтому с общим настроением вашей статьи я не согласен. На мой взгляд, неправильно воспринимать проблемы как данность и ждать для их решения появление волшебной “золотой шестерёнки” — к проблемам стоит подходить аналитически и системно.
В любом случае спасибо за статью, будет интересно почитать вторую часть.
В статусе так называемые «золотые шестерёнки» находятся чуть выше мужиков ну и соответственно знают о разработке чуть больше. Также довольно-таки важный фактор состоит в том, что «золотые шестерёнки» имеют благосклонность
авторитетовруководителей что даёт им не мало привилегий. Сами себя они никогда не назовут «золотыми шестерёнками» (так как это звучит довольно обидно) а называют они себя обычно «создающими движение бизнеса» или «ведущими».Извините, не удеражлся.
Согласен с вами, некомпетентность руководителя — насущная проблем. Но в чём польза таких историй из жизни? Просто в очередной раз побухтеть в комментариях, выпустить пар?
Поделитесь лучше своими соображениями как эту компетентность развивать, что предпринять сотрудникам, на ваш взгляд, во избежание демотивации или помощи своему руководителю.
Могу на это ответить только рассуждениями из собственной опыта.
Увлекаюсь программированием независимо от того, приносит это деньги или нет. Работаю над собственными проектами и на выходных, и параллельно основной работе.
Раньше удивлялся, почему многие люди вокруг не вкладываются в изучение технических дисциплин, с такой же упоротостью, как и я, ведь это так интересно и перспективно!
А потом как-то резко осознал, что у этих людей кроме экспертности в своей профессии есть много чего, что для меня недостижимо: семья и дети, опыт восхождения на горы, навыки в оперном пении, собственная группа по игре D&D. Всё сразу стало на свои места, и как-то полегчало.
На заре индустрия состояла исключительно из экспертов и научных деятелей, целиком увлеченных компьютерами. Но сейчас это обычная работа, не нужно удивляться что многие умеют делать тоже что и вы и получить за это деньги без каких-либо романтических и героических замыслов. Лучше поинтересуйтесь чем они таким интересным занимаются вне рабочего времени.
Знаете почему расстреливали? Потому что акт насилия происходит от бессилия, это крайняя мера, к которой прибегают когда все другие известные способы решения проблемы не получается осуществить.
Так умеют, что в советское время создавали целые направления и кружки для изучения и решения проблем менеджмента на производстве. Это всё с тех времен тянется. Познакомьтесь, например, с Щедровицким. Из его лекций можно узнать, что руководители и начальники бюро в принципе не понимали, как строить заводы и управлять производственными процессами в срок.
И что-то мне подсказывает, отсутствие обратной связи и исключение исполнителей из планирования — было одной из причин этих проблем.
А каким образом, по-вашему, руководитель группы планирует корректный срок для решения задачи?
На мой взгляд, он не может быть экспертом и практиком в той области, которой занимается исполнитель. Поэтому грамотный срок определить он может только на основе показаний исполнителя:
Сделаю за 1 день, но плохо
Сделаю за 2 дня, но потом придётся переделать за 4 дня
Сделаю за 5 дней, но хорошо
Не сделаю, вы требуете невозможного
Поэтому, грамотно обработать спущенный срок в зоне ответственности исполнителя. Я не говорю, что только он за него отвечает, но тоже отвечает, да.
Другое дело, если руководитель игнорирует комментарии и варианты сроков исполнения — это уже неадекватность. В таких случаях свою зону ответственности желательно переводить в другую компанию.
Обиделись все на то, что вы пренебрежительно отозвались о линейных разработчика, как будто бы всех их назвали бестолковыми.
После вашей разъяснений я бы сказал, что это не "линейность", а "экспертность". Ну и называть людей экспертами, всегда приятнее.
Насчет широты взглядов. Рекомендую вам ознакомится с тем, как люди понимают сам процесс изобретений и научного прогресса (например, есть история про изобретение фотоаппарата). Похоже всё сводится к тому, что изобрести новое из ничего невозможно. Новые изобретения — наблюдение и совмещение удачных идей из разных сфер деятельности, порой самых неожиданных.
В этом плане мнение даже самого узконаправленного специалиста иногда помогает сделать лучше решение инженера самых широких взглядов.
Хорошо, давайте попробуем конструктивно ситуацию разобрать. По-вашему, кто отвечает за срыв сроков? Кто не провёл достаточный анализ и подписал подрядчика на кабальные сроки? Кто решил, что единственное эффективное средство вести дела — это лояльно принимать всё, что спускают топы заказчика? Кто не разобрал причины неуспевания — то есть не учел риски подряда?
На мой взгляд, менеджер — не секретарь, чтобы передавать поручения, и не будильник, чтобы напоминать о задачах в Jira, и даже не стенографист, который записывает за другими meeting notes.
Менеджер — сотрудник, который организует, руководит и управляет рабочим процессом.
Так что невыполнение сроков полностью в зоне ответственности менеджера. Даже если у вас команда ленивых саботажников и вы физически не могли в срок реализовать задуманное. Всё равно это ваша проблема, как менеджера — вы не разобрались какая производительность у вашей команды, не нашли квалифицированных исполнителей, не подстраховали риски дополнительным ресурсом.
И да, вполне естественно, что в случае своих профессиональных ошибок менеджер при этом как человек тоже страдает и спрессует. Уверен, что любая классная команда в этот момент поддержит своего менеджера.
Но драматизировать управленческие провалы и представлять менеджера как героя не нужно. Это его ошибка, он должен её проанализировать, исправить и предотвратить в будущем, а не устраивать конфликты внутри команды.
Мне кажется, вам бы понравилось в средние века. Там многие считали, что «знание» в принципе от сатаны, засоряет не только разум, но и душу. А вот вера в кресты — единственное спасение.
Сложносоставную систему, типа фреймворка вы для кого делаете? Для инженеров или линейных разработчиков?
Вы зря недооцениваете пользу от общения с "линейными разработчикам". Даже если под этой категорией вы имеете ввиду неопытных разработчиков.
Нет ничего лучше, чем комментарий или мнение разработчика, который не хочет или не понимает "сложносоставную систему". Это всегда спасает от перегиба в дремучие, понятные и полезные только лично вам, аспекты космолётостроения.
Ну да, у программистов послушный компьютер, а у дизайнеров и иллюстраторов красивые картинки. И только у менеджеров другое — у них сложная, непохожая ни на что работа.
Есть целая категория науки, которая занимается проблемами менеджмента — это гуманитарная наука. В неё входит большое количество учебных материалов и исследований по вопросам решения менеджерских задач. Кстати, хитрости, уклонения и манипуляции сотрудниками — не входят в перечень инструментов для решения этих задач.
Только не воспринимайте мои комментарии как нападки.
Мы тут сотни статей пишем о требованиях к навыкам программиста: теория, алгоритмы, разбирайся в бизнесе, умей в софты, организуй свой рабочий процесс, оценки давай для задач.
А для менеджера у нас какие требования? Лояльность, интуиция, пару лайфхаков управления из паблика про менеджмент. Я считаю, что мы должны развеять миф о том, что на менеджера не нужно учится.
Срок, спущенный сверху, всегда является зоной ответственности исполнителя. Потому что это один из факторов принятия решения. Например, программист может применить готовый проблемный алгоритм, если бизнесу надо завтра, или придумать новый качественный за месяц, если сроки квартальные.
Также зоной ответственности исполнителя является способность дать аргументированный отказ, если сроки неадекватные.
Ответ на этот вопрос уже давно дан в книге "Мифический человеко-месяц". Достаточно осознать, что есть два вида сложности задачи: практическая и концептуальная.
Первая подразумевает что решение уже известно, нужно только его исполнить. Это любая работа, для которой уже есть алгоритм или императивная инструкция. Такие работы можно оценить с точностью 100%, их легко автоматизировать, включить в инструментарий.
Вторая подразумевает что решения не существует, его нужно найти. Оценить такие задачи невозможно никакими способами. Потому что оценивать можно только то, что известно. Это, например, новые бизнес фичи, архитектура сервиса или алгоритм обработки данных.
Любую задачу концептуальной сложности можно превратить в задачи практической сложности. Для этого необходимо проводить исследования.
Например. Прежде чем брать новую фичу в спринт, сначала провести системный и бизнес-анализ за фиксированное время. Если задача слишком сложная, этот анализ проводится несколько раз, пока всё же не будет найдено решение. И только потом это решение, декомпозированное на практические задачи, берётся в работу.
Кстати, проводить анализ можно итерациями и по 2 дня, и по 2 часа, смотря к какому темпу готова компания и команда. Так что популярный аргумент “нам некогда, нам бизнес делать надо” не работает.
Если проектный менеджер или тимлид этого не понимает, толкает в работу концептуальные задачи без исследования - никакие средства контроля и самообмана не помогут (кроме везения), сроки будут нарушены.
По-настоящему гениальный творец должен быть нищим, а его труд не ради прибыли. Это распространённое у нас представление о творчестве. Наверно, потому что звучит благородно.
На самом деле стремление получить прибыль, во многом есть стремление обрести независимость, чтобы увеличить масштаб своих возможностей. Нет ничего плохого в том, что компания выпускает игру ради прибыли.
Проблема в другом. Тот продукт, который сейчас подаётся в маинстриме под названием “игры”, называется так только из-за скудности языка:
Азартные сделки, которые вызывают привыкание
Мультимедийные проекты, стремящиеся встроится в денежный поток рынка
Мошеннические схемы для обмана
Площадки для распространения рекламы
Всё это в обёртке “игр” пытаются втюхать потребителю. Он возмущается, но всё равно потребляет, потому что сориентироваться сложно.
Вот вам простая аналогия. Люди уже десятилетиями потребляют БАДы, и некоторые, так и не поняли, что это не настоящие лекарства, и толку от них не больше, чем от свежего огурца. Хотя коробочки красивые, и выглядят как таблетки.
Так же и в игровой индустрии, современные “медийно активные добавки” являются по сути чем угодно, но не играми. Не нужно удивляться что в очередном продукте компании, которая разработчиком игр является только номинально, с вас пытаются выкачать максимум денег, а не увлечь новым опытом через игровой процесс.