Pull to refresh

Comments 21

Сколько раз каждому из нас приходилось слышать «Даю трубочку своей помощнице/секретарю/сисадмину, он сейчас вам скажет, что необходимо подправить»!
По результатам личных встреч и телефонных разговоров, на которых обсуждаются важные вопросы, Исполнитель готовит письменное резюме, которое высылает Заказчику по электронной почте.
Мы сделали так:
Поставили Mantis Bug Tracker и сказали клиентам, что бы свои хотелки писали туда. Было достаточно сложно первое время заставить людей писать, но мы устные хотелки отправляли в долгий ящик, а то что в мантисе стрались реализовать быстро, через некоторое время в результате такого подкрепления правильных действий у пользователей выработался рефлекс, что проще и быстрее написать в мантис. После этого посыпалось куча заявок на доработки существующего софта и написание новых модулей (мы внедряем учетные системы). Т.к. каждый такой чих оплачивался клиентом отдельно — мы достаточно неплохо увеличили свою выручку. Одному клиенту счет вырос где то в 6 раз, по сравнению с предыдущими. Директора это заинтересовало, он начал разбираться и выяснил, что больше половины наших доработок, вошедших в этот счет — вещь ненужная. После чего попросил делать только те доработки, которые санкционированы определенными лицами (при этом счет оплатили без проблем). Сейчас так и работаем:
— Сотрудник создает инцидент в мантисе
— Инцидент назначается одному из ответственных сотрудников
— Если инцидент нужный, то далее он назначается на нашего сотрудника, который его назначает исполнителю

Вы учили клиента на его собственных ошибках. Этот способ наиболее распространённый, но, на наш взгляд несколько негуманный :) Хотя, есть такие люди, которых иначе не научишь, что уж там.
Честно говоря — учить клиента данному не было нашей задачей, так уж само собой получилось. До этого случая мы с этим клиентом работали лет 8, честно говоря даже и не думали, что внедрения мантиса приведет к таким последствиям.
Мы тоже поставили Мантис. Так некоторые клиенты умудряются отвечать на автоматические письменные уведомление, которые Мантис и рассылает =)
У меня был случай, клиентка утверждает с пеной у рта, что пишет в мантис, а ей ни кто не отвечает. Ни одного инцидента от нее в мантисе не было зарегистрировано. Вообщем когда ситуация наколилась, начали разбираться и выяснили, что она посылает письма на адрес мантиса (с которого он шлет уведомления). Было смешно и грустно
Просто у нас настроено, что если шлют на несуществующий ящик домена, то все приходит на info@… Вот так вот спалили, как они пишут.
Мы в свое время, наоборот, всеми силами держали подальше заказчика от мантиса. В качестве прослойки использовали basecamp. Там общались менеджеры с клиентами, которые фильтровали все пожелания и в мантис складывали готовые и четко сформулированные тикеты для разработчиков.

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

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

Если говорить о размерах, то попробуйте для начала масшабировать этот подход на рабочую группу, а это, в среднем, 5-10 человек.
Ну во-первых, когда каждый выполняет именно свою работу. то работа команды получается гораздо эффективнее. Управление очень любит тратить время программистов, дизайнеров на всякие совещания, как пример. Всегда ли только это оправдано?

Основная эффективность работы каждого человека измеряется именно его работой. На мой взгляд, порядка 80% времени совещаний для дизайнеров, программистов и других непосредственных исполнителей является пустой тратой времени, которое они смогли бы провести более эффективно.

Это же можно отнести и к встречам с заказчиком например. Для встречи по проекту не обязательно вести весь свой штат.

Я согласен с тем, что иногда есть необходимость подключить исполнителя напрямую к заказчику дабы избежать эффекта испорченного телефона, но это лишь «иногда».

У каждого свое мнение на то, каким должно быть эффективное управление. Кто то применяет те или иные методы на практике, кто то является сугубо теоретиком. Тут сложно говорить, что кто-то не прав. К сожалению, нет единственной верной инструкции на все случаи жизни.
У нас нет совещаний
Я это привел как пример.

Абстрагируйте это на прямое общение исполнителей с заказчиком.

А также определите зону ответственности менеджера проекта.

Собственно, продолжение дискуссии, мне кажется, не имеет смысла. Если у вас так и это работает — значит это здорово.

Я высказал свое видение и то, как я это вижу и применяю на практике. У каждого работают свои методы. Главное — чтобы они работали :)
так я сразу и сказал, что у нас не так много людей что бы их делить
> Переписка в электронной почте является документальным подтверждением достигнутых договоренностей.
Это значит, что в суде переписка по мылу будет являться весомым аргументом или нет? Просто считается, что если нет электронной подписи, то электронное письмо можно подделать.
Это, скорее означает, что она будет принята судом в качестве доказательства.
А опыта судебного не было связанного с этим? У меня просто недавно как раз был случай, когда в суде надо было доказать, что задержка сроков была по вине клиента (который писал на мыло новые и новые доделки), а электронную почту нельзя было предоставить в качестве доказательства.
Судебного опыта (к счастью или сожалению) такого нет.
Увы, не означает, если не было электронной цифровой подписи.
Sign up to leave a comment.

Articles