Comments 50
> Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
C матами? :)
Что по теме. В общем-то вы всё сказали двумя словами, «автоматизировать процесс». Если есть процесс, то его автоматизация помогает, нет — мешает.
Ну и да.
Системы управления проектами нужны. Нужны потому что есть разные пользователи (и одна общая база на них на всех). Да, заполнять неудобно, да заполнять лень. Зато это окупается тем, что все в курсе всего и (!) всё в одном месте. Да и вообще не представляю уже давно, как можно управлять проектом без диаграммы Гантта. Этак даже не знаешь, когда всё закончится с одной стороны, с другой стороны не нужно всё держать в голове — особенно если проектов больше двух. Спасают…
C матами? :)
Что по теме. В общем-то вы всё сказали двумя словами, «автоматизировать процесс». Если есть процесс, то его автоматизация помогает, нет — мешает.
Ну и да.
Системы управления проектами нужны. Нужны потому что есть разные пользователи (и одна общая база на них на всех). Да, заполнять неудобно, да заполнять лень. Зато это окупается тем, что все в курсе всего и (!) всё в одном месте. Да и вообще не представляю уже давно, как можно управлять проектом без диаграммы Гантта. Этак даже не знаешь, когда всё закончится с одной стороны, с другой стороны не нужно всё держать в голове — особенно если проектов больше двух. Спасают…
Если процесс препарировать, потом упорядочить, потом оптимизировать, то вот в этой стадии автоматизировать его сущий пустяк.
А если процесс никто из исполнителей толком не понимает, то и автоматизация получается никому не понятная (в еще большей степени), и никто не сможет заставить этими средствами пользоваться, а если и заставит, то выйдет еще хуже — вместо одного кривого процесса два параллельных кривых процесса (второй — отражение первого в кривом зеркале автоматизации).
А если процесс никто из исполнителей толком не понимает, то и автоматизация получается никому не понятная (в еще большей степени), и никто не сможет заставить этими средствами пользоваться, а если и заставит, то выйдет еще хуже — вместо одного кривого процесса два параллельных кривых процесса (второй — отражение первого в кривом зеркале автоматизации).
игривая затея
>Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
Да и матюги будут и орфография кривая… и косяки автоматизации, например проверка почты парсером каждые 5 минут даёт задержку обновления статуса задачи по крайней мере на эти же 5 минут. Ну и как крайность — подвисание сервиса, БД, сервера… Что тоже бывает и без этого никак. Чем сложнее система автоматизации — тем она менее надёжна. Поэтому нельзя всё автоматизировать на 100% и отключить телефон — нужно подстраховываться — где джаббером, где телефоном и т.п.
Да и матюги будут и орфография кривая… и косяки автоматизации, например проверка почты парсером каждые 5 минут даёт задержку обновления статуса задачи по крайней мере на эти же 5 минут. Ну и как крайность — подвисание сервиса, БД, сервера… Что тоже бывает и без этого никак. Чем сложнее система автоматизации — тем она менее надёжна. Поэтому нельзя всё автоматизировать на 100% и отключить телефон — нужно подстраховываться — где джаббером, где телефоном и т.п.
Ну если технически, то у нас есть jabber сервер, который сообщение кладет в mq откуда ее забирает парсер, поэтому 5 минут-- это на сервере с паровой тягой.
Да и по большому счету этот лаг не важен-- для коммуникации используется IM, а парсер формирует аналитику, которая оперативно не нужна, кроме того, она может быть полезна для цепочки вида: «я закрыл»-«почему ссылка зеленая?»-«верни задачу»
Но задача конечно не тривиальная, мне кажется MS будет по силам скрестить Skype и Project- тогда и пойдет
Да и по большому счету этот лаг не важен-- для коммуникации используется IM, а парсер формирует аналитику, которая оперативно не нужна, кроме того, она может быть полезна для цепочки вида: «я закрыл»-«почему ссылка зеленая?»-«верни задачу»
Но задача конечно не тривиальная, мне кажется MS будет по силам скрестить Skype и Project- тогда и пойдет
> каждые 5 минут
Вообще, есть куча разных Push решений. В IMAP есть, есть PubSubHubbub для абстрактных данных. Фиксированные таймауты уже не нужно закладывать в новые системы, кроме случаев интеграции с legacy системами.
Вообще, есть куча разных Push решений. В IMAP есть, есть PubSubHubbub для абстрактных данных. Фиксированные таймауты уже не нужно закладывать в новые системы, кроме случаев интеграции с legacy системами.
Тема от меня уже далекая, но стиль изложения очень уж понравился. Пишите еще.
Прекрасный стиль изложения, респект!)
По поводу учета эффективности — очень часто одно только наличие учета весьма эту самую эффективность повышает. Главное — не перегибать с этим учетом палку, отслеживая время каждого похода в туалет, например :)
Уважение!!! :)
Возбудило! :)
Интересный набор мыслей, равнозначно несвязанных между собой, как набор карточек.
Особенно в тему:
«В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».»
Ох как много этого и в наших конторах, и о ужас, в заподных. При чем там этого просто дофигища.
«В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».»
Ох как много этого и в наших конторах, и о ужас, в заподных. При чем там этого просто дофигища.
Очень часто это синдром NIH. Вместо того, чтобы взять какой-то существующий фреймворк или приложение, мы пишем свой атомный подводный велосипед.
>«все что-то бегают и истерят, давайте-ка купим джиру, чтобы это прекратить»
А у нас ДВЕ системы управления для каждого проекта. Считается, что одна решает проблему «бегают», а другая — «истерят». Эффект очень неожиданный: развилась возможность одноверменного мышления над одной проблемой в двух разных категориях.
А у нас ДВЕ системы управления для каждого проекта. Считается, что одна решает проблему «бегают», а другая — «истерят». Эффект очень неожиданный: развилась возможность одноверменного мышления над одной проблемой в двух разных категориях.
Расскажите поподробней!
Мы для проекта сейчас используем обычный спредшит: один лист — бэклог, второй — баглист. В дополнение к нему подключили trello.com но он играет чисто визуальную роль — там отслеживаем текущее состояние. Но у нас команда маленькая — хватает.
Мы для проекта сейчас используем обычный спредшит: один лист — бэклог, второй — баглист. В дополнение к нему подключили trello.com но он играет чисто визуальную роль — там отслеживаем текущее состояние. Но у нас команда маленькая — хватает.
Афтар, пеши исчо!
Прямо Зощенко какой-то…
Прямо Зощенко какой-то…
Тут был соседний топик про дырявые абстракции. К системам учета и контроля тоже можно применить такие рассуждения. Эти системы оперируют понятиями которые, при определенных обстоятельствах, перестают описывать реальную ситуацию, а значит такая система начинает мешать решать реальные проблемы.
В моей практике была такая ситуация. Аутсорспроект, как полагается багтрекер заказчика, менеджеров научили всем этим пользоваться, программеры потихоньку начали разбираться как вся система работает. Началась работа, менеджеры принимают тикеты, раздают программерам, те их резолвят — вообщем все супер. Но после некоторого времени (год наверное) такая система начала сбоить. Заказчики ругаются, менеджеры ищут виновных, одни программеры засиживаются до поздна, другие увольняются. Это уже потом, когда я уволился, начал думать почему так получилось. Понятно, что сначала резолвились относительные простые тикеты, остальные тикеты труднее решить. Но менеджерам это было не понять, потому что они оперируют абстракцией — тикет, много решили — хорошо, мало — нет бонусов. Программисты конечно говорили об этом, но не так внятно, а у менеджеры уже давно научились фильтровать техническую информацию, которую грузит ему программер (как банерная слепота — за долгую практику мозг на бессознательном уровне отсекает ненужную информацию).
В моей практике была такая ситуация. Аутсорспроект, как полагается багтрекер заказчика, менеджеров научили всем этим пользоваться, программеры потихоньку начали разбираться как вся система работает. Началась работа, менеджеры принимают тикеты, раздают программерам, те их резолвят — вообщем все супер. Но после некоторого времени (год наверное) такая система начала сбоить. Заказчики ругаются, менеджеры ищут виновных, одни программеры засиживаются до поздна, другие увольняются. Это уже потом, когда я уволился, начал думать почему так получилось. Понятно, что сначала резолвились относительные простые тикеты, остальные тикеты труднее решить. Но менеджерам это было не понять, потому что они оперируют абстракцией — тикет, много решили — хорошо, мало — нет бонусов. Программисты конечно говорили об этом, но не так внятно, а у менеджеры уже давно научились фильтровать техническую информацию, которую грузит ему программер (как банерная слепота — за долгую практику мозг на бессознательном уровне отсекает ненужную информацию).
В этом плане, есть еще клевая тема-- если задача профакаплена, ее можно уже и не делать- все равно уже минус в карме.
Довольно интересное наблюдение. Ещё есть практика, что если задача сложная, её разбивают на ряд задач, объёмом не более 2-3 дней. Тогда видно, кто на чём зависает (при условии ежедневного отчёта о прогрессе) и легче соразмеряется сложность разных задач. Но вообще, если менеджеры не понимают тему и начинают думать исключительно категориями тикетов — пробуксовывание проекта обеспечено, потому что никому не выгодно делать сложные задачи, которые и сформулировать-то сложно, не говоря об разбиении на части. А такие обычно лежат в глубине решения общей задачи; если не решены — топтание на месте, латание дыр возможно, нормальное решение — нет.
Возможно, у вас проблема заключалась в наборе недостаточно грамотных менеджеров, например, из-за оптимизации их по зарплате в течение года (брали только тех, кто соглашался на низкую зарплату, но не умел работать).
Возможно, у вас проблема заключалась в наборе недостаточно грамотных менеджеров, например, из-за оптимизации их по зарплате в течение года (брали только тех, кто соглашался на низкую зарплату, но не умел работать).
Фразу «оптимизация по зарплате» я бы в кавычки взял :)
Менеджеры вообще лишние в этом деле. Общий трекер и есть менеджер, если толково заряжен. Все это программеры сделают сами, если заинтересованы в результате (всего проекта), а не тупо в закрытии тикетов.
У программеров профессия — управление сложностью, они на этом менеджменте собаку съели (хотя может сами и не догадываются). Надо их просто поставить в нужном месте в нужное время и объяснить роль в общем механизме. Вот это задача для менеджера — но не «манагера», а опытного программиста.
У программеров профессия — управление сложностью, они на этом менеджменте собаку съели (хотя может сами и не догадываются). Надо их просто поставить в нужном месте в нужное время и объяснить роль в общем механизме. Вот это задача для менеджера — но не «манагера», а опытного программиста.
При этом тебе все равно пишут в скайп: «я там открыла задачку» и «я там закрыл задачку».
Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
Только не это!
Будет тоже самое, динозавровое, только еще и с ошибками :)
А статья хорошая!
Автору — мое почтение. Очень все ярко и правильно описано.
Жалко только, что в традиционной битве разума со здравым смыслом чаще всего побеждает все-таки не здравый смысл…
P.S. Все-таки в BDSM буква D чаще подразумевает Domination, и про это тоже вполне можно было бы написать в рамках «управления разработкой».
Жалко только, что в традиционной битве разума со здравым смыслом чаще всего побеждает все-таки не здравый смысл…
P.S. Все-таки в BDSM буква D чаще подразумевает Domination, и про это тоже вполне можно было бы написать в рамках «управления разработкой».
Истину глаголишь, но истинное Domination как в Теме, так и в управлении проектами встречается чуть более чем не часто. Ведь в управлении проектами Domination это как правило роль, а не сущность. И играют эту роль как правило, хлюпики у которых эта девиация сексуального поведения развивается как психологическая компенсация. Вот уж действительно какие интересные параллели между «менеджерами» и «господами по вызову» :-)
True Domination — это когда ты зажигаешь разработчиков темой так что она становится им интересна и они работают от души. Этого не достичь ни кнутом ни пряником, ибо играя роль нижнего, они как правило нижними не являются, вот ведь какая однако девиация сексуального поведения.
True Domination — это когда ты зажигаешь разработчиков темой так что она становится им интересна и они работают от души. Этого не достичь ни кнутом ни пряником, ибо играя роль нижнего, они как правило нижними не являются, вот ведь какая однако девиация сексуального поведения.
Я один прочитал заголовок как БСДМ? =)
Есть все возможности для того, чтобы просто парсить сообщения, и строить из них отчетность— почему это никто никак не сделает?
Делают-делают, аналогичная идея появилась году в 94м, тогда же и реализовали.
Сейчас это больше похоже на wiki, т.е. все сообщения интерпретируются как wiki (с расширяемым языком разметки, что и позволяет любой фрагмент любого сообщения считать командой и «проводить» соответствующие учетные действия).
>Ага, сидит куча красноглазиков, и что они там делают— непонятно, и мало что непонятно, так еще и за очень нехилую такую зарплату.
Блин, везет же им
Блин, везет же им
Классно, но резануло: «живет мечта о боге из машины».
«бог из машины» звучит как «Deus ex machina», т.е. «выражение, означающее неожиданную, нарочитую развязку той или иной ситуации, с привлечением внешнего, ранее не действовавшего в ней фактора».
Непонятно, это очень тонкий такой стеб, игра смыслов, или немного корявый перевод?
«бог из машины» звучит как «Deus ex machina», т.е. «выражение, означающее неожиданную, нарочитую развязку той или иной ситуации, с привлечением внешнего, ранее не действовавшего в ней фактора».
Непонятно, это очень тонкий такой стеб, игра смыслов, или немного корявый перевод?
А я гляжу, пацаны-то в Теме!
хорошая статья, дельная.
мои 5 копеек относительно таск-менеджеров. Я в работе своей команды долго пытался обойтись без систем управления. Скайп и тп — это ведь достаточно? В итоге оказалось что без системы никуда. Вопрос в эффективности и удобстве — напишите свою. Мы так и сделали — основной упор делался на удобстве. Так что в итоге все довольны, а времена когда все было в чатах и тд вспоминаются с ужасом.
мои 5 копеек относительно таск-менеджеров. Я в работе своей команды долго пытался обойтись без систем управления. Скайп и тп — это ведь достаточно? В итоге оказалось что без системы никуда. Вопрос в эффективности и удобстве — напишите свою. Мы так и сделали — основной упор делался на удобстве. Так что в итоге все довольны, а времена когда все было в чатах и тд вспоминаются с ужасом.
Отличная статься, но… Эй, руки прочь от самокатов! Это святое! :)
порекомендую книгу
Записки автоматизатора. Профессиональная исповедь
Андрей Георгиевич Орлов
покупал когда еще нельзя было скачать, не жалею
Записки автоматизатора. Профессиональная исповедь
Андрей Георгиевич Орлов
покупал когда еще нельзя было скачать, не жалею
В итоге мы получаем ситуацию, когда куча ресурсов тратится на что-то непонятное и прекрасное, как песни китов: «общую шину», «суперпоиск» или «модуль сделать заебись».
Борюсь с такой фигней уже долгие годы. Кстати, тоже ненавижу программистов. Об их инфантилизме и глупости еще Ашманов в своих скрижалях писал.
Ашманов писал не об инфантилизме, и тем более глупости, а об некотором «аутизме». Это не уровень интеллекта, а скорее психологический тип, склонный к «чрезмерной» интроверсии.
Ашманов писал о некоторых типично детских замашках программеров, что свидетельствует об инфантилизме. Глупость у них присутствует не «интеллектуальная» (ибо они все, разумеется, ниибацца мозги), а глупость от неразвитости.
Аутизм программеров — это вообще песня. Аутистов я насмотрелся столько, что просто караул.
Аутизм программеров — это вообще песня. Аутистов я насмотрелся столько, что просто караул.
Мне кажется, аутизм программистов в большой степени миф, причем активно поддерживаемый самими программистами.
Велика вероятность того, что среди дворников или токарей процент аутистов не меньше.
Просто они аутично метут двор или точат деталь, и с ними не норовят пообщаться продукт менеджеры, представители отдела маркетинга, бухгалтерии или еще кто-нибудь, вызывающий острые приступы замкнутости.
Велика вероятность того, что среди дворников или токарей процент аутистов не меньше.
Просто они аутично метут двор или точат деталь, и с ними не норовят пообщаться продукт менеджеры, представители отдела маркетинга, бухгалтерии или еще кто-нибудь, вызывающий острые приступы замкнутости.
Sign up to leave a comment.
Управление разработкой в стиле BDSM