Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Chief Product Officer (CPO), Systems Analyst
Lead
From 400,000 ₽
Project management
Project planning
Strategic planning
Optimization of business processes
Automation of processes
Development management
Information Technology
Agile
Здесь я иронизирую исключительно о том, что оборудование 30 и 20 летней давности по характеристикам абсолютно out-of-date, и может использоваться только для каких-то совсем специфических задач в режиме "работает-не трогай". Более "свежие" машины, на которых может работать и обновляться современное прикладное ПО, уже допустимы, но тут важно что вы сказали - любая железяка участвующая в процессах работы компании, должна иметь возможность оперативного ремонта/замены с минимальным простоем и потерями.
Да, очень актуален работающий без перебоев сервер на базе PentiumPro 200 мГц с 512 Mb RAM и дисками по 2 Гб под управлением Windows NT 4.0 :)
Сказочная история. Набор каких-то стандартных страшилок, которые даже в единую логику увязать не удосужились. Зачем куда-то отправлять всю базу каждые 15 минут? От чего стали "пропадать данные" и "тормозить CRM", история вообще умалчивает. Бэкапы дело надо, но как это связано с "азиатским хакером"? С учётом специфики бизнеса, это вообще заказная атака со стороны конкурента, и то вот прям 20% клиентов потерялись от того что им скидку предложили. Через слово "устаревшее, устаревшее" - поставь на "устаревший" роутер не словарный пароль, и статьи не получилось бы. Заодно сэкономили бы на замене кучи работоспособного оборудования.
А другие в это время сказки рассказывают про то как сложно заменить системы иностранных вендоров, причём даже не управления производством, а учёта и контроля. Было бы желание.
Книжка кстати шикарная. Дело не в том, классика это или не очень, она демонстрирует что вся проблематика современного управления проектами уже к 1997 году была понятна, и новая статистика лишь подтверждает что ничего не меняется, проекты по-прежнему проваливаются не из-за техники, а из-за "политики". Он просто для привлечения внимания использует более кричащие термины типа "безнадёжных проектов", а внутри тот же эджайл :)
Я не ради того чтобы поспорить, или тем более кого-то переубедить - если у вас есть такой опыт здорово, мне бы правда хотелось увидеть такую команду. Если говорить про спорт, то так бывает даже не на дворовом уровне, а только когда команда просто пришла мячик попинать. Когда есть некая цель, победа в соревновании, то быстро выясняется что понимание куда идёт команда и что нужно сделать у каждого своё, особенно после неудач. Просто более активные лидеры продвигают своё видение, 80% с ними соглашается, 10% "оппозиции" уходит, а если не может то гадит в тапки.
В любом случае, лидирование должно подразумевать ответственность. А внутри она "самоорганизуется" довольно плохо, потому что с лидером спорить не любят, а пока косяки станут заметны снаружи, процесс может изрядно зайти "не туда". При этом команда проблемы может даже не заметить, или (что чаще) не просемафорить. Ибо критика токсична :)
Вы про то, что есть самоуправляющийся коллектив, который решает как ему достигать целей. Но иерархия внутри коллектива всё равно выстраивается, всегда есть ведущие и ведомые. Тимлид это не административная должность, а роль (некий лидер общественного мнения, и хороший эксперт - кто не замкнут в своих должностных обязанностях, а оказывает влияние и на коллектив, и на проект) и необходимо отслеживать кто её в коллективе занимает (их может быть и несколько), чтобы с ним обсуждать интересы компании, а не каждый раз со всем колхозом. Но это не должно быть пущено на самотёк - у него должны быть и дополнительные полномочия, и премии, и - ответственность.
Только тренд сейчас ровно обратный - либо напихать всего и побольше (откройте яндекс-Go, или любой топовый сайт который чего-то пытается продать), либо для "единообразия" сделать мобильную вёрстку для всех устройств, и получаются вот эти вот аршинные буквы и гигантские поля. И это продвигается именно лидерами рынка, а значит копируется всеми остальными.
Потому что департаментов, которым нужно свой проект продвинуть много, а главная страница - одна.
В любой самоорганизующейся команде есть самоорганизатор :). Если вы думаете что его нет - значит вы его просто не видите. Как того суслика. Просто если он появился без вашего участия, то и действовать он будет в каких-то своих интересах, и не факт что они совпадают с вашими.
Так языки программирования и придумали из-за того, что человеческий язык очень плохо подходит для описания алгоритмов! В нём слишком много неоднозначностей (вероятно, это как раз фишка для общения людей). А эволюция от машинных кодов через ассемблер и далее - это лишь следствие развития вычислительной техники и средств разработки. Как органы управления автомобилем - по сути мало чего изменилось с первых машин, только становилось удобнее и эргономичнее. А хочется управлять машиной силой мысли.
Интересно, а кем установлен факт её жизни в диком племени? Это её галлюциногенные фантазии.
Не раскрыта только тема, где взять нормальных специалистов и консультантов. Почему на прорабе хотят сэкономить практически все кто хоть немного в стройке понимают? Да потому что это не просто человек который на всех орёт, а забирает себе минимум половину суммы, поэтому из оставшихся денег нанимает самых дешёвых бестолковых рабочих, ещё и материалы тырит при первой возможности. С ИТ тоже самое. Если человек ничего в этом самом ИТ не понимает, то и консультанта он наймёт, который с умным видом разведёт его на деньги.
Никаких внешних консультантов, если ИТшная история не сервисная функция, а базовая для бизнеса, то минимум один из основателей должен в ней хорошо разбираться, иначе они просто спустят деньги инвесторов. Впрочем, сейчас это похоже основная бизнес-модель стартапов, но это уже другая история :)
А необходимость стратегического планирования - я уже устал об это твердить, но обычно бесполезно, вокруг мир победившего "эджайла".
Перечитал статью - да, адок получился ещё тот, но мне кажется что из-за того что вовремя не остановились. До какого-то уровня формализация процессов приносит пользу - вы сами писали что обнаружилась куча неэффективных мест в процессах, халтурящих сотрудников - а потом система стала пожирать людей, чуть ли не физически (увольнения, нервы, орки). Инструмент для анализа ситуации и сбора метрик превратили в карающий орган, и ад начался именно тогда. То что после PS достойно отдельной статьи - а какие элементы оказались полезными, когда стоит остановиться?
Я про то что внедрение регламентов и инструкций сначала увеличивает эффективность работы, потом эффект становится разнонаправленным, но после какого-то момента начинается обратный процесс снижения эффективности, вплоть до драматичного статью бы написал, но к сожалению не писатель.
Отсканить пачку газет и натравить распознавалку - само по себе неплохо, большая работа, OCR отработал хорошо учитывая исходники. Но вот ИИ-то здесь где? Чтобы именно похвастаться, могли хотя бы разбиение на колонки корректно отработать, не говоря уж про переносы, там совсем банально. Опять, образец применения высоких технологий людьми, которым пофигу на результат.
Медный лом в штатах стоит ~3.5 usd за фунт, т.е. сопоставимо с китайскими ценами. Вероятно, что-то напутали с единицами измерения.
Надо же чем-то занять тучу сотрудников, вот и придумывают задачи по решению проблем, которых нет. Компания с чистой прибылью 1.5 трлн может себе позволить.
Да, это то что я хотел услышать - что задачи таки распределяет специально обученный человек. Обычно когда пишут про управление приоритетами, создаётся впечатление что они как-то сами собой выстраиваются, а про то что задачи с одинаковым приоритетом надо тоже приоритизировать как-то умалчивают - кстати вероятно отсюда получается не 4, а 44 приоритета.
Разумеется, не каждую мелочёвку, может быть пул задач которые действительно всё равно когда делать - но это скорее из приоритета "неважные несрочные".
В моей практике такая приоритизация нужна в поддержке, багфиксах - там, как вы написали, борьба идёт за их корректную маркировку, и обеспечение исполнения низших приоритетов.
А вот с разработкой как-то не складывается - каким образом работать с задачами одного приоритета - сортировать их по дедлайну? ИМХО сомнительная практика ждать пока важная задача превратится из несрочной в срочную. Обычно между задачами есть взаимосвязи, поэтому крайне желательно их реализовывать не когда захочет разработчик, а относительно синхронизировано (например, когда имплементация новой фичи затрагивает несколько модулей, и для её работы необходимо реализовать во всех - даже тех для которых она стоит с низким приоритетом).
Поэтому я ставлю приоритеты не на отдельные задачи, а на фичи, которые в свою очередь расставляю в порядке оптимальности технологического процесса разработки, и особого места этим градациям там нет, они группируются не по важности, а по логике этапов функциональности.
А при чём тут UX? Это вообще-то User eXperience. Там ни слова нет по то, как при этом выглядит UI - User Interface, который, внезапно, может быть реализован различными способами, не обязательно графическим. Опять какой-то бестолковый наскок "внедряйте ИИ и будет вам счастье".
Попытки внедрить голосовой интерфейс ведутся уже давно, и без всякого ИИ - но даже там, где это технически работало нормально, выясняется что люди просто не хотят разговаривать. На мой взгляд это весьма небольшая прослойка людей, которые любят поговорить, пытается навязать своё представление о прекрасном основной массе. Когда заказ такси превратился из бесконечных диалогов с оператором в нажатие трёх кнопок в приложении, использование такси выросло кратно.