Яких помилок в управлінні програмними продуктами слід уникати, щоб люди не ненавиділи продавця?

Попереднє питання було закрито про те, чому люди ненавидять Microsoft. Це спроба дещо конструктивнішого питання за тією ж загальною лінією. Цей спосіб є і ширшим, і вужчим. Більш загальне, якщо говорити про постачальників програмного забезпечення взагалі, а не лише про Microsoft. Це вужче, займаючись лише управлінням програмними продуктами.

Отже, які кроки потрібно вжити (та / або уникати) в управлінні окремими програмними продуктами, щоб переконатися, що не тільки окремі продукти, але й компанія в цілому поважаються / подобаються / сприймаються у позитивному світлі?

Найголовніше, очевидно, - поставити якісний продукт.

Інші важливі теми:

• Чесність. Не брешіть, коли правда рано чи пізно з’явиться.
• Надійність. Дотримуйтесь строків.
• Доступність. Відповідайте на електронні листи, піднімайте телефон.
• Готовність до співпраці Якщо це означає співпрацювати з найближчим конкурентом, щоб зробити те, що потрібно замовнику, зробіть це і зробіть це професійно. Жодних брудних хитрощів, які б зашкодили спочатку клієнту.

Останній пункт у моєму списку - це, мабуть, те, що МС набуло такої поганої репутації (хоча, я думаю, вони зараз значно кращі); і ще гірше, коли це роблять невеликі компанії.

Невичерпний список, починаючи з двох, які можуть пройти довгий шлях до створення справді пристрасних клієнтів, тих, хто вийде зі шляху, щоб просувати ваш товар.

• Чуйна, шаноблива модель підтримки. Нічого, як бути швидким та надавати своїм клієнтам добру підтримку. В ідеалі модель прямого реагування. Навіть з такою моделлю підтримки громади, як веб-сайт дошки оголошень, де кожен може задати питання, і будь-хто може відповісти на запитання, однак модерація та насіннєве обслуговування співробітників допоможе. Стара сенсація щодо обслуговування клієнтів - надайте комусь хороше обслуговування клієнтів, і вони можуть розповісти про це одній людині. Надайте їм неякісне обслуговування клієнтів, і вони скажуть 10 людей. У веб-світі, що зараз 10 людей, множиться багато разів.

• Використовуючи хороший дизайн - ви хочете націлитись на насолоду людей. Для цього потрібна не лише інженерія, але і дизайн - прослуховування клієнтів, перегляд їхніх плечей, складання прототипів та постійне вдосконалення випущеної продукції.

Ще два я додам:

• Якість - так, тримаючи щільну кришку від кількості помилок, не відпускаючи, поки вона не стане твердою. Зосередження уваги на міцному продукті, а не на лускатому, який має перевантаження. Я пам’ятаю, колись під час несамовитості веб 1.0, великий постачальник оголосив, наскільки здоровим є можливість розробляти програмне забезпечення ітераційно без реального процесу якості при розробці веб-сайтів. Приблизно в той час я спробував один з їхніх нових сайтів, і він на мене зламався майже одразу. Здавалося, зрозуміло, що перед випуском НЕ було тестування. Хороший спосіб відволікти своїх союзників і відвернути нових клієнтів.

• Модель ліцензування, яка добре працює на те, як люди будуть використовувати програмне забезпечення. Люди знають, що їм потрібно платити, але якщо ви можете відобразити гнучкість, яку потребують люди у вашій політиці, то це працює для всіх. Приклад: ліцензії на місце, що дозволяють використовувати декілька комп'ютерів або робочий та домашній комп'ютери. Тому що багато людей мають більше одного комп’ютера.

- Олексій

Деякі способи бути ненависними:

Торгуючи та продаючи свій бізнес-продукт, націліться на людей, які мають купівельний орган, яким не доведеться ним користуватися. Тоді вам не доведеться турбуватися про зручність використання.

В ідеалі ціноутворення повинно бути заплутаним і нераціональним. Майте кілька версій з функціональністю, яка чітко не відрізняється. В ідеалі є одна або дві особливо бажані функції, що вищі за цінову шкалу, тому люди отримують відчуття, що їм доведеться платити велику суму за багато речей, якими вони не користуватимуться.

Якщо у вас є достатня потужність, робіть пізніші версії програмного забезпечення не зовсім сумісними з попередниками, і не пропонуйте знижки на оновлення. Щоб отримати додаткові бали, видаліть функціонал, до якого люди могли звикнути.

Рекламуйте функції, які насправді не працюють. Якщо у вас є достатній контроль над продуктом, видаліть його з більш-менш вимушеними оновленнями.

Залиште кілька помилок, бажано, переривчасті помилки. Придумайте причини, якщо, якщо щось трапиться, це не ваша вина. Стоунвул ваші клієнти, що скаржиться. Крім того, придумайте виправлення, яке насправді робить продукт менш придатним для використання.

Контроль якості призначений для компаній, які хочуть задовольнити клієнтів. У вас багато потенційних бета-тестерів: використовуйте їх. Ви отримаєте звіти, навіть якщо ви не дасте їм відгуків. Ви можете виправити багато з них у наступній версії (див. Вище про незначні несумісності, відсутність ціни на оновлення та видалення функціональних можливостей).

Плутати комп’ютери користувачів. DRM тут чудовий, особливо якщо ви не повідомляєте нікому про це достроково (особливо, якщо вони не очікують DRM на щось подібне до вашого продукту).

Заходи проти піратства - чудові. Переконайтеся, що ваші алгоритми виявлення мають багато помилкових позитивних результатів. Не обов’язково мати зручні чи прості способи виправити помилкові позитиви.

Тривалі плутанини EULA, які заявляють про смішні речі, є звичним явищем в наші дні. Щоб ненавидіти їх, вам потрібно закопати там щось важке та примусити його згодом.

Документація призначена для сутенерів. Переконайтеся, що практично неможливо зрозуміти, як зробити кілька важливих речей із документів. (На жаль, з часом це стало занадто поширеним, щоб стати дійсно ефективним.)

Знижки, які потребують незручної документації та процедур подання заявок, є хорошими. Пам’ятайте, що сьогодні багато квитанцій друкуються таким чином, що з часом затухає, тому ви можете зекономити багато грошей, вимагаючи оригінальної квитанції та витрачаючи достатньо часу на їх обробку.

Тут завжди корисні зарозумілість та широко розкрита антиконкурентна практика.

(Немає балів здогадуватися, які пропозиції я писав, маючи на увазі компанії, або навіть які, або які я зазнав особисто.)

1) Створіть якісний продукт
2) Розумійте клієнта
3) Підтримуйте послідовність

Ціна відкритим і зрозумілим способом - це включає не тільки початкову ціну придбання, але оновлення, додаткові функції або модулі, підтримку, консультації, навчання та будь-які інші пов'язані з цим витрати.

Ви не повинні бути дешевими, ви можете цінувати настільки агресивно, як вам подобається, але одне на моєму досвіді, яке більше засмутить клієнтів, якщо мова йде про ціну, - це незрозумілі екстри та ідея, що у них більше грошей несправедливо витягнуті з них тепер вони зробили покупку.

Невідомі витрати - це не гроші, а репутація людей. Особа, яка здійснює покупку, поставила частину своєї репутації, коли планує бюджет на проект. Навіть якщо додаткові витрати мають співвідношення ціни і якості, коли ви повинні повернутися до свого начальника і попросити більше грошей, ви змушуєте їх публічно визнати, що вони накрутили, і вони за це вас зненавидять.

Утримання позитивної програми програмної компанії передбачає обидві сторони угоди.

Компанія повинна:

1. Постійно надайте код, який найбільше відповідає їх призначенню в обраних полях
2. Слід бачити, що постійно прагнуть до вдосконалення, діючи на відгуки клієнтів
3. Будь справедливим

Клієнт повинен:

1. Надайте відгуки компанії про те, що вони працюють добре / погано
2. Будьте розумні у своїх очікуваннях відповідей

З цих простих правил природно випливає багато хорошого. Біда в тому, що ринкові сили та конкуренція є тим, що є, дотримуватися їх - це кошмар.

Коли ви велика корпорація, як Microsoft, Google або Facebook, що має багато експозиції в новинах, ви не можете перешкодити людям ненавидіти вас. Це неможливо.

Чим більше ви успішні , тим більше вас ненавидять .

Постачальник повинен створити показник, який називається " hatemeterдля вимірювання свого успіху"! ;)

Ось чому одна з найбільших якостей підприємців здатна це зрозуміти і впоратися. І що ще важливіше, використовуйте погані відгуки для вдосконалення своїх продуктів (будь-які відгуки цікаві).

Справжні виклики, з якими стикаються продавці, - це не ненависть, а байдужість .

EDIT : Я знайшов цей дуже цікавий веб-сайт . Це дозволяє кожному висловити свою думку про різні популярні компанії та товари. Кількість голосів занадто низька, щоб зробити результати актуальними, але те, що цікаво виборцям, має пояснити, чому. Я дозволяю вам розкрити коментарі і судити про себе людська природа є складною.

Дозвольте мені обговорити це з точки зору комерційного програмного забезпечення, яке я використовував, що зводило мене з розуму.

Занадто велика гнучкість - це критично важливо. Не дозволяйте, щоб ваше бажання запропонувати гнучкість означає, що ви відмовитесь від проектування функцій, які хотіли б більшість людей. Я ніколи не використовував "гнучкий" продукт, який користувачі фактично любили користуватися. Вони не хочуть з'ясовувати, як виправити помилки дизайну. У нас є "гнучке" програмне забезпечення для управління проектами від відомого постачальника, яке залишатиметься безіменним. Настільки гнучко, що у нього немає таких речей, як поле для клієнта, який подав заявку на проект (Просто скільки компаній достатньо великі, щоб потребувати продукт, який коштує десятки тисяч доларів, не потрібно мати можливість сортувати проекти за клієнтом? Це було б нуль.). Коли ви перетворюєте ідею чи інцидент у проект, інформація не автоматично переміщується до проекту, шукаючи деталі про те, що хотілося чи хто хотів, що це надзвичайно дратує, оскільки розробники насправді не спроектували систему, оскільки вона була настільки "гнучка". Складність спроб додати поля, а потім виправити всі форми, щоб ви могли побачити ці поля, означає, що майже всі відмовилися від використання продукту для всіх "чудових" функцій, які він нам продав як такі, що використовуються і лише для документування час. Взагалі, чим гнучкіша система, тим більше людей буде ненавидіти її. функції, які нам продали як такі, що мають, і використовувати їх лише для документування часу. Взагалі, чим гнучкіша система, тим більше людей буде ненавидіти її. функції, які нам продали як такі, що мають, і використовувати їх лише для документування часу. Взагалі, чим гнучкіша система, тим більше людей буде ненавидіти її.

Відсутність уваги до продуктивності, бажаючи бути нейтральною до бази даних, а не писати найкраще діючий код, який може бути специфічним для бази даних.

Відсутність тестування в середовищі із сотнями одночасних користувачів та великим набором даних у базі даних. Запити на базу даних, які добре працюють для малих наборів даних, часто є великими для великих баз даних. Колись я працював у кол-центрі, у якому була добре відома програма для центрів дзвінків, для переходу з одного екрана на інший може знадобитися десять хвилин. Ви можете собі уявити, наскільки сподобалось і тим, хто приймав дзвінки, і користувачам. Нашою найпоширенішою помилкою був тайм-аут у базі даних.

Зміни заради змін. Ніщо не дратує користувачів більше, ніж отримувати нову версію чогось, що переставляє, як робити все, і все ж не додає жодних функцій, які вони хотіли чи потрібні (див. Office 2007 та хитру стрічку, яку вони додали, та структуру меню, яку вони видалили). Мені не хочеться переучувати речі, від яких я залежаю від щоденного року або двох років, і навіть більшість користувачів. Одне з них вивчити нові технології для кращого вирішення проблем, а інша річ просто перевпорядкувати графічний інтерфейс, щоб ви не змогли знайти усі речі, які ви вже вміли робити.

Обслуговування клієнтів. Якщо у мене є проблема, я хочу, щоб ви допомогли мені виправити її швидко і без того, щоб це коштувало занадто багато, особливо якщо я заплатив величезну суму за програмне забезпечення.

Смішно глючно програмне забезпечення. Давай, я не мав змоги зламати це, виконуючи звичайні завдання звичайним чином. Ви тестували цей матеріал, чи не так? Це особливо прикро, коли ви потрапляєте на помилки під час встановлення або перші пару днів користуючись продуктом. Ще більше дратує, коли речі, які чудово працювали в останній версії, вже не працюють. Звичайно, у всіх кодах є помилки, ми це знаємо, але найбільш очевидні повинні бути приручені перед доставкою.

Щодо компанії, яка робить це правильно - я стверджую, що Red-Gate - це ця компанія. Їх матеріал просто працює, він робить те, що, на його думку, повинно робити без особливих проблем з мого боку, щоб скористатися ним, це швидко, і обслуговування їх клієнтів чудово. Практично кожен досвідчений сервер SQl-сервера, який я коли-небудь знав, рекомендує купувати їх інструменти.

Погана документація та немає бажання її вдосконалювати - я зараз працюю з постачальником програмного забезпечення, який не в змозі дати мені жодних визначень чи діаграм бази даних. Вони насправді рекомендували просто зателефонувати одному з розробників, оскільки вони є "словниками даних, що переходять". Тепер я буду знати, чому вони не вдосконалюють додаток чи виправляють помилки; вони занадто зайняті поясненням того, що знаходиться в таблиці клієнтів.

EDIT: Тепер я знаю, чому вони не документували цю базу даних:

1. Існує умова іменування імен полів на основі типу: dt = дата, s = string / varchar, d = float
2. Немає первинних ключів лише унікальних кластерних індексів.
3. Жодних обмежень на жодних таблицях.
4. Більшість збережених процедур містять: Виберіть *
5. Усі ключові поля - це рядкові типи (найменше проблем)
6. Курсори неохайні!
7. Вони зробили коментарі та номер версії своїх виправлень, але це про це.