Pull to refresh

Comments 50

> Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
C матами? :)

Что по теме. В общем-то вы всё сказали двумя словами, «автоматизировать процесс». Если есть процесс, то его автоматизация помогает, нет — мешает.

Ну и да.
Системы управления проектами нужны. Нужны потому что есть разные пользователи (и одна общая база на них на всех). Да, заполнять неудобно, да заполнять лень. Зато это окупается тем, что все в курсе всего и (!) всё в одном месте. Да и вообще не представляю уже давно, как можно управлять проектом без диаграммы Гантта. Этак даже не знаешь, когда всё закончится с одной стороны, с другой стороны не нужно всё держать в голове — особенно если проектов больше двух. Спасают…
Если процесс препарировать, потом упорядочить, потом оптимизировать, то вот в этой стадии автоматизировать его сущий пустяк.

А если процесс никто из исполнителей толком не понимает, то и автоматизация получается никому не понятная (в еще большей степени), и никто не сможет заставить этими средствами пользоваться, а если и заставит, то выйдет еще хуже — вместо одного кривого процесса два параллельных кривых процесса (второй — отражение первого в кривом зеркале автоматизации).
>Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
Да и матюги будут и орфография кривая… и косяки автоматизации, например проверка почты парсером каждые 5 минут даёт задержку обновления статуса задачи по крайней мере на эти же 5 минут. Ну и как крайность — подвисание сервиса, БД, сервера… Что тоже бывает и без этого никак. Чем сложнее система автоматизации — тем она менее надёжна. Поэтому нельзя всё автоматизировать на 100% и отключить телефон — нужно подстраховываться — где джаббером, где телефоном и т.п.
Ну если технически, то у нас есть jabber сервер, который сообщение кладет в mq откуда ее забирает парсер, поэтому 5 минут-- это на сервере с паровой тягой.
Да и по большому счету этот лаг не важен-- для коммуникации используется IM, а парсер формирует аналитику, которая оперативно не нужна, кроме того, она может быть полезна для цепочки вида: «я закрыл»-«почему ссылка зеленая?»-«верни задачу»

Но задача конечно не тривиальная, мне кажется MS будет по силам скрестить Skype и Project- тогда и пойдет
— «я закрыл #902985»
— «а в #902985 ссылка зеленая и в #346224 надо увеличить фонт»
— «верни #902985 и открой #346224»

Вы будете запоминать тикеты?

Придумываете себе франкенштейна, супер мегапоиск. :)
Тулбар «последние задачи» -> клик #902985 -> «закрыть»

> каждые 5 минут
Вообще, есть куча разных Push решений. В IMAP есть, есть PubSubHubbub для абстрактных данных. Фиксированные таймауты уже не нужно закладывать в новые системы, кроме случаев интеграции с legacy системами.
Тема от меня уже далекая, но стиль изложения очень уж понравился. Пишите еще.
Прекрасный стиль изложения, респект!)
По поводу учета эффективности — очень часто одно только наличие учета весьма эту самую эффективность повышает. Главное — не перегибать с этим учетом палку, отслеживая время каждого похода в туалет, например :)
Безусловно, нужно всегда соблюдать баланс между отчетностью и здравым смыслом.

Взгляд с другой стороны баррикад: учет эффективности может очень здорово повышать учитываемую эффективность, т.е. разработчик просто делает то, что система считает работой.
Интересный набор мыслей, равнозначно несвязанных между собой, как набор карточек.
К сожалению, часто чтобы связать мысли нужно плодить лишние смыслы, что не хорошо.
А так, да вы правы, у меня есть такая проблема, но не по отдельности же их выкладывать
Особенно в тему:
«В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».»
Ох как много этого и в наших конторах, и о ужас, в заподных. При чем там этого просто дофигища.
Очень часто это синдром NIH. Вместо того, чтобы взять какой-то существующий фреймворк или приложение, мы пишем свой атомный подводный велосипед.
>«все что-то бегают и истерят, давайте-ка купим джиру, чтобы это прекратить»

А у нас ДВЕ системы управления для каждого проекта. Считается, что одна решает проблему «бегают», а другая — «истерят». Эффект очень неожиданный: развилась возможность одноверменного мышления над одной проблемой в двух разных категориях.
Расскажите поподробней!

Мы для проекта сейчас используем обычный спредшит: один лист — бэклог, второй — баглист. В дополнение к нему подключили trello.com но он играет чисто визуальную роль — там отслеживаем текущее состояние. Но у нас команда маленькая — хватает.
Ох, мы то же самое сделали в итоге.
Афтар, пеши исчо!
Прямо Зощенко какой-то…
Тут был соседний топик про дырявые абстракции. К системам учета и контроля тоже можно применить такие рассуждения. Эти системы оперируют понятиями которые, при определенных обстоятельствах, перестают описывать реальную ситуацию, а значит такая система начинает мешать решать реальные проблемы.

В моей практике была такая ситуация. Аутсорспроект, как полагается багтрекер заказчика, менеджеров научили всем этим пользоваться, программеры потихоньку начали разбираться как вся система работает. Началась работа, менеджеры принимают тикеты, раздают программерам, те их резолвят — вообщем все супер. Но после некоторого времени (год наверное) такая система начала сбоить. Заказчики ругаются, менеджеры ищут виновных, одни программеры засиживаются до поздна, другие увольняются. Это уже потом, когда я уволился, начал думать почему так получилось. Понятно, что сначала резолвились относительные простые тикеты, остальные тикеты труднее решить. Но менеджерам это было не понять, потому что они оперируют абстракцией — тикет, много решили — хорошо, мало — нет бонусов. Программисты конечно говорили об этом, но не так внятно, а у менеджеры уже давно научились фильтровать техническую информацию, которую грузит ему программер (как банерная слепота — за долгую практику мозг на бессознательном уровне отсекает ненужную информацию).
В этом плане, есть еще клевая тема-- если задача профакаплена, ее можно уже и не делать- все равно уже минус в карме.
Довольно интересное наблюдение. Ещё есть практика, что если задача сложная, её разбивают на ряд задач, объёмом не более 2-3 дней. Тогда видно, кто на чём зависает (при условии ежедневного отчёта о прогрессе) и легче соразмеряется сложность разных задач. Но вообще, если менеджеры не понимают тему и начинают думать исключительно категориями тикетов — пробуксовывание проекта обеспечено, потому что никому не выгодно делать сложные задачи, которые и сформулировать-то сложно, не говоря об разбиении на части. А такие обычно лежат в глубине решения общей задачи; если не решены — топтание на месте, латание дыр возможно, нормальное решение — нет.

Возможно, у вас проблема заключалась в наборе недостаточно грамотных менеджеров, например, из-за оптимизации их по зарплате в течение года (брали только тех, кто соглашался на низкую зарплату, но не умел работать).
Фразу «оптимизация по зарплате» я бы в кавычки взял :)
Менеджеры вообще лишние в этом деле. Общий трекер и есть менеджер, если толково заряжен. Все это программеры сделают сами, если заинтересованы в результате (всего проекта), а не тупо в закрытии тикетов.

У программеров профессия — управление сложностью, они на этом менеджменте собаку съели (хотя может сами и не догадываются). Надо их просто поставить в нужном месте в нужное время и объяснить роль в общем механизме. Вот это задача для менеджера — но не «манагера», а опытного программиста.
UFO just landed and posted this here
При этом тебе все равно пишут в скайп: «я там открыла задачку» и «я там закрыл задачку».
Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?

Только не это!
Будет тоже самое, динозавровое, только еще и с ошибками :)

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

P.S. Все-таки в BDSM буква D чаще подразумевает Domination, и про это тоже вполне можно было бы написать в рамках «управления разработкой».
Истину глаголишь, но истинное Domination как в Теме, так и в управлении проектами встречается чуть более чем не часто. Ведь в управлении проектами Domination это как правило роль, а не сущность. И играют эту роль как правило, хлюпики у которых эта девиация сексуального поведения развивается как психологическая компенсация. Вот уж действительно какие интересные параллели между «менеджерами» и «господами по вызову» :-)

True Domination — это когда ты зажигаешь разработчиков темой так что она становится им интересна и они работают от души. Этого не достичь ни кнутом ни пряником, ибо играя роль нижнего, они как правило нижними не являются, вот ведь какая однако девиация сексуального поведения.
Я один прочитал заголовок как БСДМ? =)
Да, все прочитали как БДСМ :)
В данном случае это вовсе не BSD!
Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?

Делают-делают, аналогичная идея появилась году в 94м, тогда же и реализовали.
Сейчас это больше похоже на wiki, т.е. все сообщения интерпретируются как wiki (с расширяемым языком разметки, что и позволяет любой фрагмент любого сообщения считать командой и «проводить» соответствующие учетные действия).
UFO just landed and posted this here
>Ага, сидит куча красноглазиков, и что они там делают— непонятно, и мало что непонятно, так еще и за очень нехилую такую зарплату.
Блин, везет же им
Классно, но резануло: «живет мечта о боге из машины».
«бог из машины» звучит как «Deus ex machina», т.е. «выражение, означающее неожиданную, нарочитую развязку той или иной ситуации, с привлечением внешнего, ранее не действовавшего в ней фактора».

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

мои 5 копеек относительно таск-менеджеров. Я в работе своей команды долго пытался обойтись без систем управления. Скайп и тп — это ведь достаточно? В итоге оказалось что без системы никуда. Вопрос в эффективности и удобстве — напишите свою. Мы так и сделали — основной упор делался на удобстве. Так что в итоге все довольны, а времена когда все было в чатах и тд вспоминаются с ужасом.
UFO just landed and posted this here
Отличная статься, но… Эй, руки прочь от самокатов! Это святое! :)
порекомендую книгу
Записки автоматизатора. Профессиональная исповедь
Андрей Георгиевич Орлов

покупал когда еще нельзя было скачать, не жалею
я читал в скачанном варианте. атомная бомба, а не книжка :) советую почти всем кто в теме :)
В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное, как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».


Борюсь с такой фигней уже долгие годы. Кстати, тоже ненавижу программистов. Об их инфантилизме и глупости еще Ашманов в своих скрижалях писал.
Ашманов писал не об инфантилизме, и тем более глупости, а об некотором «аутизме». Это не уровень интеллекта, а скорее психологический тип, склонный к «чрезмерной» интроверсии.
Ашманов писал о некоторых типично детских замашках программеров, что свидетельствует об инфантилизме. Глупость у них присутствует не «интеллектуальная» (ибо они все, разумеется, ниибацца мозги), а глупость от неразвитости.

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

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

Просто они аутично метут двор или точат деталь, и с ними не норовят пообщаться продукт менеджеры, представители отдела маркетинга, бухгалтерии или еще кто-нибудь, вызывающий острые приступы замкнутости.
Профессия по-любому накладывает отпечаток. Аутичных сейлзов я пока не видел.
Sign up to leave a comment.

Articles