Fail review: спілкування з клієнтами

[«Fail review» — рубрика, в якій ми збираємо історії про робочі провали: що відбулось, як виправляли і які висновки зробили.]

Непорозуміння, культурні та національні відмінності, нестача комунікації, технічні проблеми — причин факапів у спілкуванні з клієнтами вистачає. А історій, що змушують червоніти або сміятись (і чомусь вчать!) — ще більше. ІТ-спеціалісти діляться власним досвідом.

Про важливість юзер-сторі

Станіслав Семухін, Senior Android Developer у GlobalLogic

На одному з попередніх робочих місць сталася дуже характерна історія.

То був внутрішній продукт однієї з українських аутсорсингових компаній, яким власник керував на рівних правах з партнерами. Ці партнери були, як заведено на типовому стартапі, і фаундерами, і продакт-оунерами, і бізнес-аналітиками.

Ми робили мобільні застосунки для цього продукту під iOS та Android. Я займався розробкою Android-версії.

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

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

Але все ж таки я опанував себе й створив юзер-сторі, в яку вклав своє примітивне розуміння, як це повинно працювати. Кидаю йому в командний чат посилання на свою юзер-сторі й прошу внести корективи.

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

Насправді він створив свою юзер-сторі, написав про це в чаті, попросив нас робити все по ній, але забув заасайнити її на мене.

Тож я 2 тижні робив задачу, керуючись своїми хибними уявленнями, як це повинно працювати. І от спливає спринт, підходить час демо.

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

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

Я, звичайно, показую той варіант, який імплементував на основі створених мною юзер-сторі (він був далекий від завдання, як від Марсу).

Звичайно, бачу непорозуміння, що наростає серед глядачів, але йду до кінця. Після демо цей продакт-оунер ставить просте запитання: «Що це?». Я відразу кидаю посилання на свою юзер-сторі, за якою я це імплементував. Він робить ще ширші очі й повторює те саме запитання вже стосовно моєї юзер-сторі.

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

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

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

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

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

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

Коли бюджет закінчується

Денис Костін, Project Manager у Digital Cloud Technologies

Одного разу, багато років тому, ми з командою робили невеликий пробний проект для однієї з фондових бірж. Ключовим моментом були строки. Треба було якнайшвидше зібрати команду, долучаючи всіх без обмежень. З боку клієнта був молодий активний менеджер, який сам розподіляв роботу й контролював скоуп. Працювали ми на T&M. Усе було гарно й позитивно до того моменту, коли він раптом сказав мені, що в нього вже закінчується бюджет, а ми ще не зібрали напрацьоване докупи та залишалося ще багато цікавих і потрібних ідей. Анонсований же дедлайн був ще далеко...

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

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

Верблюже молоко, манговий сік і робоча неділя

Микола Кульпа, Product Manager у Comarch Poland S.A.

Працюю Product Manager у компанії Comarch (Польща) уже понад рік. Ще на початку співпраці потрапив на кастомізацію продукту (проект з арабським клієнтом (країну, на жаль, назвати не можу), що тільки почав використовувати наш продукт і хотів підтримку SLA).

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

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

Ніхто не попередив, що я повинен виходити на роботу в неділю. Уже в обід, коли я, відіспавшись, вирушив на закупи до найближчого торговельного центру, мені на приватний номер (службовий ще не встиг зробити) зателефонував невідомий арабський номер. Це був клієнт, який проінформував, що вони відмовляються від SLA, оскільки на честь мого прибуття прийшов сам СТО фірми, аби традиційно вручити мені фірмовий шарф, а я попросту не з’явився!

Беру таксі й лечу з пакетами їжі, пакетом KFC і трилітровою банкою молока, до якої було прив’язано акційний манговий сік. На контролі пояснюю, що я працівник onsite й мені дуже терміново потрібно на зустріч. Мене відмовляються пускати, оскільки я не мав документів, а лише українські автомобільні права, написані невідомою їм мовою. Знаходжу якесь фото закордонного паспорта, нагадую, що на мене чекає СТО, і чую, напевно, найгірше: «Is it you Nick from Comarch?» Повертаюся й бачу перед собою старшого араба в білій мантії. Мило відповідаю, що це я, і починаю перепрошувати за запізнення й пояснювати, що на мене чекає зустріч із СТО.
На це чоловік відповідає, що зустрічі не буде, бо він має бігти, але запрошує мене з понеділка знову прийти до офісу та, посміхаючись, дає мені візитівку й шарф.

І так, це був той самий СТО мого клієнта... Наступний діалог я запам’ятав на все життя:
— Do you like camel milk?
— Camel milk! What do you mean?
— Dear Nick, U have a big bottle of camel milk in your hand.
— OMG! Facepalm...

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

Гроші — не головне

Олександр Литвиненко, Tech Lead

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

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

Я працював з ними кілька років, і щоразу, як роботодавець казав: «Я хочу крутий продукт!», я давав йому цей крутий продукт. Але MLM — це не там, де крутий продукт, це там, де все зроблено абияк, половина функцій не працює, а в апдейтах важлива не якість, а кількість.

Саме тоді я чітко зрозумів, що не хочу так працювати й знайшов свою нішу: якісні та технологічні продукти.

Конфлікт із тим замовником почався відразу, як стали співпрацювати. На момент старту я займався складними проектами в дуже стислі строки, коли все горить (був молодий, і здоров’я дозволяло). Саме з таким проектом він прийшов до мене: строки нереальні — півтора тижня (MLM — це high load). Ми погодили, що система створюється з розрахунку на 10 тис. одночасних користувачів, але тільки для поточного функціонала. Після старту мені дадуть час на вдосконалення системи.

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

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

А потім, спілкуючись із першим замовником, почув фразу, що й сформувала моє ставлення: «Тобі просто треба було сказати йому, що все ОК. Він уклав би гроші й нікуди вже не дівся б». Я запитав: «А хіба це не обман?» На що у відповідь почув: «Я вже й забув, що є люди, для яких гроші — не головне».

Завдяки цьому досвіду я сформував своє ставлення до ведення бізнесу. Я не заробляю мільйони, але мені вистачить на старість. Мої клієнти — адекватні люди, які прийшли за якістю. І працювати з ними — задоволення.

Клієнти — теж люди

Alex Fogol, Software Developer, C/C++ Expert у Selene Associates

Спілкування з клієнтами — нескінченна історія. Одного разу ми з клієнтом погодили специфікацію протоколу, яким мали спілкуватися між собою окремі програмні частини, і кожен зі свого боку почав розробляти прототипи. Це було дуже важливо, бо прототипи мали показати великому начальству, щоб продемонструвати прогрес (виділяйте бюджет і шліть гроші).

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

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

Так і сказати. Головне — не боятися. А ще бути ввічливим.

Отже, іду до клієнта й кажу: «Хлопці, тут у нас, напевно, якась проблема, геть дрібне непорозуміння. А дайте-но я гляну ваш код, бо ж мені треба налагодити свій. Тож я подивлюся, як вони там, дві програми, між собою спілкуються».

Дають. А я вже знаю, що шукати, тож знаходжу відразу. Кажу: «Ой, тут не так, як ми домовлялися, але зараз швиденько виправимо, то не страшне, то з усіма трапляється!» Ще година пішла на те, щоб знайти, як то треба зробити мовою програмування клієнта, і от маємо: програми почали спілкуватися! Клієнт щиро вражений і задоволений та має що показати своєму великому начальству. Клієнт стоїть на нашому боці в питанні підписання контракту. Чистий профітЪ!

Ця тактика досить проста: якщо виникає проблема, слід ставати не на свій бік, не на бік клієнта, а саме на бік, що проти проблеми. І так само ставити туди й клієнта. Тож ми (я, ви й клієнт) — на одному боці, а проблема — на іншому. І це працює! Я перевіряв.

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

І суть моралі в тому, що «такі самі люди» геть не означає «такі, як я сам». Вони — інші. Вони можуть не бачити проблему під тим самим кутом, під яким бачу її я. Навіть коли для мене це очевидне. Тому ніяк не можна ставити себе на місце клієнта. Слід саме очікувати, що ми й вони бачимо це — просто одне й те саме — по-різному.

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

Хотіли як краще, а вийшло...

Andriy Bas, Co-founder Uptech

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

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

Під час розмови ми зрозуміли, що product-market fit — нечіткий, а жодного аналізу не проводили. Потреба продукту на ринку була особистим припущенням. Аргумент клієнта був: «Ти ходиш на каву? От бачиш, усі, з ким спілкувався, ходять на каву, тож сервіс буде популярним».

Ми, винятково через бажання допомогти, розказуємо, що є от у нас якраз для його кейсу такий процес Discovery, під час якого ми проведемо user research, зрозуміємо цільову аудиторію, розробимо прототип і протестуємо його перед будь-якою розробкою. Мовляв, так правильно робити, так він заощадить гроші й це максимізує його шанс зробити успішний продукт. Адже це найпопулярніша помилка, якої припускаються засновники, і якої ми йому допоможемо уникнути.
І що ви думаєте? Замість того щоб прислухатися до нашої поради, він образився. Розгнівався, що ми не поважаємо його ідеї та ставимо під сумнів його компетенцію. Звісно ж, йому не потрібне ніяке тестування, бо продукт напевне буде успішний, і він це сам знає.

Ми так і не змогли знайти спільну мову. Він закінчив розмову. Звісно, ми не продовжили роботу. На жаль, не знаємо, як його «успішний проект» зараз поживає.

Отак, намагаючись допомогти, інколи залишаєшся винним...

Мистецтво компромісу

Володимир Яцевський, Chief Executive у LiveArt

Одного разу до нас звернувся клієнт з Німеччини, що мав власний продукт з онлайн-верстки друкованих матеріалів. Попередня версія була виконана з допомогою Flash, а тому клієнт шукав можливості переписати його на HTML/JS стек. Не буду вдаватись у технічні подробиці, але ідея проекту полягала у «схрещенні» нашої технології зі стороннім RTE-редактором (Rich Text Editor). Зі свого боку ми повідомили, що спочатку це буде суто R&D проект, який ми не можемо конкретно ні оцінити, ні гарантувати результатів.

І ось тут нас чекав провал. Попри всю комунікацію, представники клієнта продовжували вважати проект досить тривіальним, обмеженим у часі і бюджеті, без особливих ризиків. Коли ж ми представили кілька MVP і почали вказувати на недоліки сторонніх бібліотек, які ми не були в змозі подолати, незадоволення клієнта наростало. Він вважав, що дефекти можна виправити в рамках того ж бюджету. Ситуація продовжувала загострюватись: клієнт не отримав очікуваного результату, нам було не вигідно продовжувати R&D проект на умовах фіксованого фінансування та відсутності розуміння характеру проекту клієнтом.

Одного дня я отримав досить однозначного листа: «виправте дефекти у рамках бюджету, або ми працюємо з вашими конкурентами і закриваємо проект». І комунікація, і сам проект опинились у патовому стані. Усі пояснення та посилання на попередні листи та домовленості натикались на одну відповідь — «you have to fix it as promised».

У цей час я натрапив на книгу Chris Voss «Never split a difference». Її лише нещодавно переклали у нас як «Ніколи не йдіть на компроміс». Впавши у відчай від перспективи втратити цікавого клієнта, я зважився використати метод каліброваних питань у відповідь на всі жорсткі вимоги клієнта. Це був типовий наївний експеримент: я лише прочитав частину книжки, а сам метод випробував хіба що на своєму синові, який якраз переживав кризу трьох років. Відправивши першого листа, я вже подумки очікував відповідь від комерційного директора компанії-клієнта з вимогою повернути проектні кошти... Здавалось, вся команда затамувала дихання. Усю розробку було поставлено на паузу.

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

Правило великого пальця і як у нас «віджимали» проект

Денис Братчук, директор по инжинирингу, GlobalLogic

Самые очевидные «факапы», которые случались во время общения с клиентами — это те, которые были замечены немедленно. Канонический пример — микрофон, который случайно оказывается включённым во время звонка, и позволяет собеседнику услышать то, что не было предназначено для всех.

Однажды при удалённом общении с потенциальным партнёром по бизнесу и обсуждении проекта, в котором мы совместно собирались принимать участие, один из представителей партнёра произнёс: «Я занят, на звонке, отжимаем проект у компании такой-то». Стоит ли говорить, чем закончился этот звонок, а с ним и наше едва начавшееся сотрудничество?

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

Куда сложнее и нетривиальнее проблемы, которые связаны с неправильной коммуникацией, но не обнаружены своевременно. По моему опыту, чаще всего это происходит в ситуации, когда что-то меняется, но последствия изменений недостаточно прозрачно озвучены клиенту:

Один из менеджеров написал клиенту, что добавление на сайт новой страницы займёт 40 часов и одну рабочую неделю. Заказчик сказал, что его это устраивает. Когда после добавления страницы клиент получил счёт за потраченные сорок часов, он отказался его оплачивать. Он был согласен подождать лишнюю неделю, но не ожидал, что это будет стоить ему дополнительных денег.

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

Правило большого пальца в таких ситуациях очень простое. Когда на проекте что-то меняется, лучше потратить больше времени на общение и пройти по всем потенциально рискованным пунктам, нежели надеяться, что клиент всё поймёт и так.

Смакуючи чіпсами, вимикайте мікрофон

Андрій Кладочний, Frontend/SharePoint Developer

Добігала кінця фаза розробки продукту, і потрібно було презентувати напрацювання широкому колу представників клієнта: працівникам ІТ-департаменту, менеджменту, керівникам підрозділів — усього майже 10–15 особам. Хтось із боку клієнта, під’єднавшись до презентації, забув вимкнути мікрофон і почав, прицмокуючи, смакувати чипсами. Залізна витримка нашого BA допомогла йому закінчити презентацію, попри це звукове тло.


Історії ІТ-спеціалістів, які поділились фейлами на умовах анонімності

Смайлик чи дужечка?

Не то чтобы факап, просто забавная история.

Был клиент, американский стартап, все общение в основном в чатиках: с мемами, сленгом, иногда даже нецензурными словами.

Попросил доступ на сервер, который до этого меинтейнили наши сисадмины. Высылаю аs is: логин + пароль примерно такой: 574Fa8qj).

Клиент не может зайти под этими кредами, мы (команда) заходим без проблем. После получасовых разбирательств (подозрение было на недоступность сервера извне или из другого региона) оказалось, что клиент думал, что «)» в конце пароля — смайлик.

Як різниця часових поясів врятувала від фейлу

Це були мій перший робочий тиждень у новій компанії й перше завдання, яке мені дали розв’язати.

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

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

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

Це точно був не найкращий початок нової роботи.

3000 євро за пару днів

Однажды я перепутал сотни с тысячами и указал стоимость проекта на пару дней в 3000 евро вместо 300. Что интересно, заказчик спокойно заплатил. Такой вот случай, когда плохое знание английского оказалось полезным.

Hi gays!

На своем первом зарубежном проекте я писала письма для команды в США, начиная словами «Hi gays!» Они молчали две недели, потом корректно попытались выяснить, почему я так делаю. Было очень стыдно и смешно — ребята были с чувством юмора.


Ще більше фейлів на співбесідах та робочі провали.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn



Найкращі коментарі пропустити

Прочитал первую историю — исполнитель же сам виноват в том что не понял что от него хотят. И кстати сам этого еще не понял.

По поводу чипсов. Нет ничего постыдного в том, чтобы сказать что-то вроде «Извините, я слышу какой-то шум, он мне мешает. Будьте добры выключить микрофон». После этого человек, который хрустел чипсами, поймет свою вину и возможно даже сам извиниться. Зачем терпеть?

Залізна витримка нашого BA допомогла йому закінчити презентацію, попри це звукове тло.

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

Текст от Фоголя с запятыми. Не верю! :)

100 коментарів

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

Первая статья полнейший фейл.
Сам виноват в своей невнимательности, не хотел признать ошибку в отсутствии коммуникации с клиентом. Не инициировал проверку QA. Обнаружив что работает с разными юзер стори не прокоммуницировал об этом, и свалил вину на всех вокруг.
Статья заканчивается личным персональным позитивом. Сбежал с проекта оставив всю команду и клиентов разгребать.

Уважаемая Александра.
Я очень ценю Ваш вклад, как аналитика в объективную оценку меня, как разработчика.
А теперь давайте по сути, кто для чего нанят на проект.

В задачи разработчика входит:
1) Выбор архитектур, технологий и инструментов для реализации проекта согласно спецификации.
2) Собственно, реализация проекта согласно спецификации.
3) Взаимодействие с командой в соответствии с принятым в рамках проекта процессом.

Что произошло?
Процесса на проекте не было.
Спецификации не было. На вопрос разработчика «могу ли я добиться чётких требований к реализации от человека, которому нужен этот проект», был получен ответ «этот проект нужен только тебе, если ты хочешь работать в этой компании».

Ещё раз напоминаю, что коммуникация на проекте — это ответственность менеджера.
И в задачи разработчика не входит компенсация менеджерских фейлов. Точно так же, как в задачи менеджера не входит фикс багов, сделанных разработчиком.
И если разработчика пытаются за те же деньги пригрузить менеджерскими обязанностями, он совершенно справедливо задаст вопрос «кому нужна такая работа?».

И то, что я оставил их самих разгребаться с тем ужасом, который они натворили своими руками, моё полное право. Я никого не обманул и никому ничего не должен сверх оговоренного в контракте и при трудоустройстве. У нас был не брак и совместные дети с этой командой, а всего лишь рабочие отношения на основании договора.
Если одну из сторон условия сотрудничества устраивать перестают, они разрываются согласно оговоренной процедуре без всяких сантиментов.
Крепостное право на территории нашей страны отменили в 1861 году.
Всхлипы «на кого ж ты нас оставил», давно неактуальны.

По поводу чипсов. Нет ничего постыдного в том, чтобы сказать что-то вроде «Извините, я слышу какой-то шум, он мне мешает. Будьте добры выключить микрофон». После этого человек, который хрустел чипсами, поймет свою вину и возможно даже сам извиниться. Зачем терпеть?

Полностью согласен!

После этого человек, который хрустел чипсами, поймет свою вину и возможно даже сам извиниться.

Или проигнорит (а может и даже не услышит) и будет хрустеть дальше.

К счастью, не стыкался. Но предпочитаю с людьми

Разве это невозможно? Хрустит так, что аж не слышит.
Повторюсь, не попадалось такого. Но всё бывает

Одного разу, багато років тому, ми з командою робили невеликий пробний проект для однієї з фондових бірж. Ключовим моментом були строки.

Так г-о код еще не называли :)

P.S.
Скорее всего просто очепятка

Я имел в виду «сроки,» мой украинский ещё не нейтив пока. )

Всё нормально, «строк» — законное слово. (Многие предпочитают альтернативное «термін», но это уже вопрос вкуса.)

А в чому проблема слова «строки»? Цілком собі нормальне українське слово, синонім слова «терміни».
r2u.org.ua/...​ll&dicts=all&highlight=on
Варто мені оновлювати коментарі перед дописом :)

що клієнт шле мені цифри словами

Чорд.
Або тут щось реальне замасковане, або... мені вже просто кортить послухати, що це був за клієнт (не конкретне імʼя, а тип), що додумався слати цифри словами.

одразу ж перевірив як я пишу. все ок)

Можна будь-ласка пояснити, що є метод каліброваних питань?

Дякую за запитання. Відповім фрагментом книжки яку відтепер усім раджу прочитати — nashformat.ua/...​]/2/2[_idParaDest-1]/1:0

Каліброване питання — це будь-яке питання виду «How am I supposed to do that?» / «Як мені це зробити?». Але його не застосовують самим по собі, а як правило в купі з іншими техніками.

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

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

Мож ещё заказчик сам пусть и сделает? На моей памяти людей, которые не могут сами шагу ступить не очень жалуют

Почитайте книгу. Это совсем не об обычном процессе сбора требований и elicitation. Там бы я порекомендовал Вигерса и, если проект на стадии сейла, SPIN методику Рэкхема.

книг столько что все не перечитать, из того что ты говоришь эта книга — вредные советы, заказчик приходит с проблемой и ждет ее решения, а в ответ «решай сам»

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

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

применительно к нашей сфере это когда в проекте складывается патовая ситуация, некий цугцванг, когда любая сторона выдвигает требования от которых проигрываешь ты и проигрывает другая сторона. и вот здесь есть ряд методик которые помогают решить эту проблему и выиграть.

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

возможно, в книжке и написано как растянуть время доения клиента, но он в итоге откажется от проекта из-за нерентабельности

нужно заменить людей на ключевых позициях

Ага, у клиента :)

либо я чет пропустил, либо речь была не о технических решениях изначально, иначе не складывается

не о технических решениях изначально

Да.

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

то поставить стресоустойчивого менеджера с ролью «терпила» между заказчиков и командой

Вот пока это сформулировано в таких магических терминах, это и есть «мышки, станьте ёжиками».
А вся тема больше посвящена раскрытию того, что внутри этой магии, как и почему она может не работать.

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

у відповідь на будь яку вимогу ставите питання «але як мені це зробити?»

це тролінг )) тобто у випадку з fbi це працює бо вони там ну такоє не сказать би б шо аж прямо генії усі і задачі їх теж «радше забалакати ніж досягти результату» але конкретно коли на проекті таке то я вже навіть навчився поратися з таким «тролінгом»

отже ти чуваку кажеш «зроби» а він тобі «але як мені це зробити?» отже це етап № 0 після чого переходимо до етапу № 1 і справді складаємо досить детальний план виходячи з ролі чувака (саме тому джуни на _бойовому_ проекті то є завжди єрунда) і чувак відповідно отримує конкретні п.п. «роби раз роби два» але далі починається найцікавіше ))

позаяк така «методика» то є конкретно тролінг і за fbi я вже сказав як вони його викорустовують і це правильно але у випадку «роботи» ситуації зазвичай 2 № 1.1 чувак просто бере і робить молодець! № 1.2 чувак прямо або не прямо каже «ні так робити не буду буду (якось отак) (у т.ч. ніяк)» доречі останній варіант і спостерігається тут у треді ))

Тож насправді етап № 1 це такий собі «пастка антитролінг» і якщо чувак до нього потрапляє — так з моєї практики чувака 146% «на мороз» чим раніше тим ефективніше для проекту бо ж «можна ще трохи дати йому шанс» працює 146% однаково і це просто коштуватиме щось проекту питання тут хто важливіший чувак чи проект але то вже питання не до мене ))

ЗЫ: загалом особисто я радив би б дуже уважно і обережно ставитися до «тактик fbi та спецслужб» бо так вони працюють але питання у тому як саме і у якому саме оточенні і яке саме оточення ви хочете побудувати у своїй компанії чи у чужій компанії просто навколо себе та по відношенню до себе але так само тут ще існує певне питання «лицемірства» нехай навіть незумисного коли сидять от такі чуваки і кажуть «ну тіпа нам тута надо особистий контакт бо ми будемо ставити питання і слідкувати за твоєю реакцією» а воно мені так смішно бо то вони думають шо то вони тіпа як той чувак з fbi а насправді воно навпаки тіко без «тіпа» ))

Я дуже раджу придбати книгу і самому у всьому розібратись в деталях — там є дуже багато тонкощів і реальних історій.

але тут +1 з усіма тіма «зауваженнями» що я тут зауважив хоча... втім то же ж несуттєво бо дивись п.п. «вони думають шо то вони тіпа» так що навпаки особисто мені навіть вигідно да? ))

Почитайте книгу. Не думаю, що там до «тролінгу» коли на тому кінці дроту вгашений чувак, який може перестріляти заручників. Історії FBI — це просто екстремальні випадки. У своїй же роботі такі випадки трапляються у мене лише з клієнтами і то дуууже рідко, т.к. з складними/конфліктними клієнтами просто невигідно працювати у довгу.

бо так вони працюють але питання у тому як саме і у якому саме оточенні

Саме так. Бо:

Суть проста — у відповідь на будь яку вимогу ставите питання «але як мені це зробити?»

Ой не завжди діє, мʼяко кажучи. Якщо клієнт на емоціях і таки дійсно хоче щось здобути (не обовʼязково те, що формально каже!) — так. А якщо ні, або він більш досвідчений... Одна з типових відповідей тут — це треба показать в дії на акторах, але повинно бути
1) тяжкий уздох.
2) погляд як на щось мілке, брудне, надоїдливе, але якого не можна позбутись — прилипло і не відчепляється,
3) спокійним тоном, повільно, наче крізь силу, можна почати дійсно крізь зуби: «Мені вас рекомендували як професіоналів. Дуже неприємно чути такі питання, що показують, що ви не відповідаєте вимогам ринку.»
Текст буде різнитись, саме такий буде тільки на перших 1-2 зустрічах, але принцип не змінюється.

Якщо впало в таке — далі тільки в кого шари залізніші. І це не формалізується.
Або ж пробувать винайти дійсні мотиви. Типово, що представник замовника не зацікавлений у проєкті, бо проєкт не працює на його карʼєру. Тоді... не буду рекомендувати, що робити в такому випадку :)

Дякую за коментар!
Повірте :) і такі відповіді і зустрічі у ролях були. Звісно це все не так просто і потрібно дуже багато зусиль і емпатії щоб все це разом спрацювало. І ви також праві — певні речі формалізації не піддаються, це свого роду мистецтво, особливо у живих переговорах віч на віч. Клієнт з прикладу не найгірший випадок — у мене були і такі які робили так як ви описали, і що відверто і постійно маніпулювали, і зрештою нікому це жодного гешефту не принесло.

Найкращий перемовник поки що — це мій син, який навчився розпізнавати вже багато методик і вміє з них виходити якщо намагається досягти свого. Перемовинам ми вчимось все життя і це навчання не припиняється жодної миті. Сам автор описує і свої відверті фейли і фейли перемовника ФБР мають значно більшу ціну ніж, скажімо, мої.

Сам автор описує і свої відверті фейли і фейли перемовника ФБР мають значно більшу ціну ніж, скажімо, мої.

ще раз ви надто плутаєте цілі фбр та скажімо свої

Якщо впало в таке — далі тільки в кого шари залізніші. І це не формалізується.

Ледве не ключова проблема усіх цих «тактик спецслужб» у тому що вони «читаються». І щойно «клієнт» «прочитав» що ви «робите тактику» все ви вже потрапляєте у незручне становище дуже схоже на згаданого тут

один из представителей партнёра произнёс: «Я занят, на звонке, отжимаем проект у компании такой-то».

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

Тут цікавий момент якраз у тому що розумні люди і так між собою домовляться а фішка цих книжок якраз у тому що «тактики» подаються як «дієвий інструмент доступний посередньостям» і найперша природня реакція на це «класична»

www.youtube.com/...​nAw&feature=youtu.be&t=54

Спасибо! Надо почитать.
Забавно что я в каком то упрощенном виде сам к этому пришел :) я называю это «вовлечение» — т.е. «заставлять» (так как добровольно не многие заказчики хотят) включаться в архитектуру/тех.детали/как это должно или может быть устроено или работать и т.д., это заставляет их задумываться как это и что это на более конкретном уровне. А также потом помогоет обьяснять почему мы не можем что то сделать, почему нам нужны изменения и т.д, ну и меньше сюрпризов «ой! а мы думали там все по другому!».

Верно! Хотя это больше для решения ситуаций типа «сделайте как фейсбук или я вас всех уволю!» =)

Однажды я перепутал сотни с тысячами и указал стоимость проекта на пару дней в 3000 евро вместо 300. Что интересно, заказчик спокойно заплатил. Такой вот случай, когда плохое знание английского оказалось полезным.

Плохое знание чего-чего ?!?

Наверное имеется в виду что перепутал 3 hundreds и 3 thousands :)

а я-то думаю, сколько правильно нулей надо по-английски писать в слове «3000 евро» :8))

Настає моя черга для демо. Присутні продакт-оунер, який ставив мені задачу, iOS-розробник, QA (які під час спринту так і не знайшли час хоч раз подивитися на Android-застосунок)

ну це трешак повний, як куа, я з впевненістю скажу що це вина куа

Там провина колективна. Але більш за всіх винен ПО.
Починати спринт, не створивши та не заасайнивши юзер сторі на тих, хто повинен їх імплементувати — це норм?)

Так, погоджуюсь, провина колективна. Мабуть мені простіше розглядати цю ситуацію зі своєї сторони :)

Станіслав — не хотів комментувати вашу розповідь і переходити до суперечок, звинувачень, та переходити на особистості :) Але не втримався коли прочитав вашу відповідь :)))
Моя особиста приватна і субїективна думка: складаеться враження що ви ні тоді не зрозуміли, ні зараз не розуміете — що ця розповідь і ситуация — це ваша вина.
Ви порушили разом усі 4-и відомі принципи:
— Individuals and Interactions over processes and tools
— Working Software over comprehensive documentation
— Customer Collaboration over contract negotiation
— Responding to Change over following a plan
І що прикро не бачите проблем. Сеньор рівень це не тільки професійна кваліфікація, це зрілість процессів, ставлення, гнучкості, широти погляду.

Починати спринт, не створивши та не заасайнивши юзер сторі на тих, хто повинен їх імплементувати — це норм?)

це не норм звичайно, але це норм з другої сторони. Це реальність :) Якщо люди йдуть за вищевказанними принципами — то з ними можна стартувати спринт взвагалі без юзер сторів :), а якщо не йдуть — то завжди знаходиться якась фігня в «супер-процесах» хтось-шось не зробив («не заасайнив» наприклад) і нічого не робиться. Це все-одно що розробник цілий спринт нічого не робив бо із-за доступу в Jira він не бачив свої таски и борд взагалі, і весь спринт гордо чекав доступу і мовчав — бо це не його робота, це вина іншої людини.

Це мое бачення, не маю за мету переконувати вас.
Не звинуваю вас. Просто даю свою оцінку тому що прочитав: я би сприймав вашу поведунку як саботаж.

Ви порушили разом усі 4-и відомі принципи:

Вперше про них чую.
Чому Ви вважаєте їх догмами?

Якщо люди йдуть за вищевказанними принципами — то з ними можна стартувати спринт взвагалі без юзер сторів :)

І витратити весь спринт на уточнення того, що можна було за пару днів описати в юзер сторі.

Weeks of coding can save hours of planning.

Це все-одно що розробник цілий спринт нічого не робив бо із-за доступу в Jira він не бачив свої таски и борд взагалі

Ця проблема легко вирішується менеджером на першому ж дейлі мітингу. Я на поточному проекті зараз не мав доступу до клієнтської джири. Сказав про це менеджеру. Наступної години експорт усіх тасків з джири був у мене на почті.

Це мое бачення, не маю за мету переконувати вас

Ви ставите результати вище процесів.
Це не вірно. Головне — це процес.
Коли він є — результат є практично неминучим.
Коли процесу нема, результат є підсумком героїчних зусиль команди, які того не варті, бо забудуться і наступного разу це не допоможе.

Дякую за корректну відповідь! :)
Я зрозумів — ми з вами люди різних світоглядів. :)

Вперше про них чую.
Чому Ви вважаєте їх догмами?

Ой всьо...

А мені дуже сподобалося, як менеджер та бізнес-аналітик вчать програміста його роботу робити.
Мабуть, мені треба було перечитати весь беклог, знайти ту кляту сторі, самому на себе їі заасайнити, героїчно виконати. Так, ПО би це сподобалось, я не сперечаюся. Лише кинув клич, по скайпу за 5 хвилин все пояснив — гребці взяли весла та все швиденько на льоту заімплеиентували. Самі все виявили, самі протестували, заичайно ж йому це буде до вподоби. І йому все одно, що заради цього кількість годин на мітингах та кларіфвкейшенах перебільшить кількість годин на розробку. Його не буде цікавити, що людям доведеться по 5 разів за спринт переписувати якийсь модуль, через це сидіти у клятому офісі по 12 годин на добу.
Зате у поважного ПО буде більше часу на спілкування з потенційними клієнтами, за рахунок зекономленого часу на написання юзер-сторі!
Це ж все на користь великого та святого Продукту!
Найбільш проактивного веслувальника він навіть зробить лідом.
А розумна людина просто піде в іншу компанію, де процес розробки нормальний, не вимагає витрачати половину спринту на кларифікацію, все йде за планом і ніхто не переробляє, переписуючи по 5 разів той самий модуль.

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

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

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

Бачите, фейли якраз і виникають на стику подібних речей — ПО вирішив «скинути» на вас і не проконтролював, ви вирішили підійти формально і не спитали фідбеку. Скрам-мастера (якщо це був скрам) поруч не було. Конфлікт і проблему ніхто не підняв аж до демо коли звісно пізно було розбиратись. І ви, і ПО зафейлили по-своєму що призвело до глобального непорозуміння і фейлу на проекті.

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

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

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

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

Таку помилку може допустити будь-хто, вона суто механічна. Не помітив одне з повідомлень в групі, буває.
Але що у нас:
1) Сторі добавлені в спринт, але ні на кого не заасайнені.
2) Тестувальник жодного разу не подивився на білд протягом спринта.
3) ПО не перевірив беклог жодного разу протягом спринта та гадки не мав у кого яка таска в прогресі.
Це вже, вибачте, клініка.
Щоб цей проект працював хоч якось, потрібен неабиякий героїзм всієї команди.

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

ок, поясню детальніше.
ви пишете сторі про фічу яку геть не розумієте та відправляєте її продакт оунеру. На що він вам відповідає. Ви не розуміючи сенсу написаного продовжуєте кодити дуже сумнівну сторі з власної фантазії. Вам не спадало на думку що тут щось не те? Чому вам не спало на думку хоч раз подивитися на прогрес чи послухати того ж IOS дева, який, як ви вказали, таки знайшов правильну сторі і зробив її.
Облиште перекладати вину на всіх навколо вас і відкриєте справжню гармонію командної роботи. Світ не обертається навколо розробників.)))

Почитайте про ценности Скрама, раз уж работаете по Скраму.
Скрам — это не спринты, дейли и демо, это чуть другое.

Печально, что лычка Senior есть, а понимание ответственности, организованности, взаимопомощи, уважения, смелости отсутствует.

Печально, что лычка Senior есть, а понимание ответственности, организованности, взаимопомощи, уважения, смелости отсутствует.

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

Всегда, пожалуйста. Вы только забываете одну вещь — разработчик нужен не ради кода, который он пишет, и не ради тасочек, который он закрывает. Разработчик, да и любой другой участник команды/проекта, нужен для того, чтобы решать бизнес-задачи. Продукт, который должен получиться не выходе — это не 100500 строк кода, а РЕШЕНИЕ КОНКРЕТНОЙ задачи. Вот с этим, мотивированные лычками, не справились.

Вы только забываете одну вещь

Не забываю.

Вот с этим, мотивированные лычками, не справились.

1. Не думаю, что такой человек мотивирован лычками, как бы вам или кое-кому в этой теме этого ни хотелось.

2. В чём его вины меньше 1/10, и в этой 1/10 он признался. А накинулись как за полную.
(Вангую: если бы я тут не сделал примечание, кто-то бы стал стыдить за попытки такого измерения.)
А вот почему накинулись, по привычке, или вспомнив со стыдом свои провалы (при том, что будучи ПМ/etc., были основными ответственными за них), или пытаясь внушить на будущее другим читателям темы, что они должны брать на себя даже проблемы неспособного руководства — это вы можете ответить себе сами. Публично — тоже полезно, но на это я не надеюсь.

Всегда делал и буду делать больше чем от меня ожидают, и всегда старался брать на себя больше ответственности, чем предусмотрено по роли, если позволяли.
Соответственно, такого же ожидаю от других.
Вы ж не будете отрицать, что приятнее работать с людьми, на которых можно положиться в любой момент, которые подстрахуют, укажут, подскажут, помогут, чем с такими «я две недели фигней страдал, таску не делал, потому что на меня не заассайнили».
Ну и не буду лукавить, весь промежуточный контроль, со стороны, управляющих проектом, да, просран 1000%.

ПС И хватит уже набрасывать, чего мне, или другим, хочется или не хочется, у вас плохо получается.

Всегда делал и буду делать больше чем от меня ожидают, и всегда старался брать на себя больше ответственности

В правильной обстановке — аналогично. Но только до тех пор, пока на мне не начинают откровенно ездить от этого.

А там, по описанию, ровно это и случилось — на авторе попытались ездить.

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

Не фигнёй страдал, а честно реализовывал то, что знал. (Всё равно пытаетесь подтасовывать на ровном месте, не надо так.)

Да, приятнее. Но опять же — есть вещи, в которых подобная самоорганизация недостаточна.

Ну и не буду лукавить, весь промежуточный контроль, со стороны, управляющих проектом, да, просран 1000%.

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

ПС И хватит уже набрасывать, чего мне, или другим, хочется или не хочется, у вас плохо получается.

Набрасывать — это из другого типа поведения. Меня всегда в таких спорах интересует что-то выяснить для себя, а не покормиться эмоциями, или что-то подобное.

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

Не в курсе сложившийся ситуации но стартовать спринт без сторей — это не правильно.... Аджайл — это не отсутствие документации а адекватный её размер ... если вся документация — только стори — то без заполненных сторей — полный провал ПО

если вся документация

Саме так і було.
Я, звичайно, міг підстрахувати ПО та все розрулити сам, видавши в кінці спринта конфєтку.
Але наступного спринта ПО вирішить «ви, любі, у мене вже так видрєссірувались, що я взагалі не буду писати ніяких сторі — за 10 хвилин поясню по скайпу суть і ви все самі зрозумієте і зробите».
Працювати в такому режимі мене, м’яко кажучи, не влаштовувало. Пошуки іншої роботи на той час вже тривали. Нажаль, по моєму профілю у моєму тодішньому місті роботи було небагато.

Полностью согласен что это неправильно, и про документацию. Я это написал буквально —

це не норм звичайно

Зачем цепляться к мелочам? Я не говорю что так (например без сторей) — нужно стартовать все спринты! Но если случиться такой спринт (условно один раз) в силу разных причин, то при наличии нормальной коммуникации и ответсвенности — можно сделать задачи спринта, можно дописать стори к концу спринта, а во время спринта на словах\бумажках\стенах донести суть сторей. Вот в чем суть моего комментария.
А если формализм преавалирует на сутью и здравым смыслом общей и коллективной цели , как в данном исходном расказе — из серии — «он (ПО) сделал стори, скинул в чат, сказал всем следовать ей, но не заассайнил ее на меня, из этого я сделал вывод что моя собственная стори не дубль вовсе — а правильная и нужная, и я ее делал, а потом ему логи показал» — то это....это хуже ИМХО чем провал ПО :)

можно дописать стори к концу спринта,

- Это невозможно все стори должны быть готовы ДО НАЧАЛА Планирования спринта что-бы оценить сколько времени/попугайчиков на неё потребуеться

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

Это невозможно все стори должны быть готовы ДО НАЧАЛА

 — не могу :) Я же не троль какой-то что бы отвечать «Это невозможно что бы задачи которые были оценены и взяты в спринт — не были сделаны ДО КОНЦА СПРИНТА» :)

Как было сказанно во 2м коментарии этой большой ветки — провтык был коллективным виноваты были все даже КюАй который не запланировал/не успел в результате неправильного планирования протестировать .... (не буду оценивать кто больше виноват) но это была явно не вина ТОЛЬКО девелопера (хотя он тоже напартачил изрядно — посмотреть в джиру иногда нужно)

Но если случиться такой спринт (условно один раз) в силу разных причин, то при наличии нормальной коммуникации и ответсвенности — можно сделать задачи спринта, можно дописа

Там это был один из первых спринтов, в которых я пытался заставить этого ПО написать если не спеки, то хотя бы юзер стори хоть на что-то.
Он попытался и это сптхнуть на меня. Я даже согласился в итоге. И всё равно вышла ерунда.
Но виноват, безусловно, всегда программист.

А то что это обнаружилось только через 2 недели — на демо провал «Срам» мастера ибо на дейлике ЕЖЕДНЕВНО должны присутствовать SCRUM Master, SCRUM Product Owner и SCRUM Team

ЕЖЕДНЕВНО должны присутствовать SCRUM Master, SCRUM Product Owner и SCRUM Team

Все присутствовали.
Я говорил, что делаю мою стори, по тому самому модулю. Какая именно это Стори (моя, или ПО) никто не уточнял. Потому что никто не заглядывал в бэклог. Всем было наплевать.
В общем, солдаты в окопах никогда не победят, какой бы героизм не проявляли, если мудрые генералы завели их в котёл.

Ви порушили разом усі 4-и відомі принципи:

_Він_ порушив? Щось не бачу свідоцтв до цього.

я би сприймав вашу поведунку як саботаж.

Не виконувати те, про що гадки не має, тому, що не може застосувать /dev/telepathy, щоб знайти ту саму гадку — це саботаж?
Не виконувати роботу за ПМ, чи як його там звали в цьому проекті — це саботаж?

Тоді, дійсно, як ви писали нижче —

ми з вами люди різних світоглядів. :)

і я не хотив би з вами стикатися у роботі. Без смайлів.

Про початкову свою помилку він розповів. Але, що це призведе до того, що буде дублюючий документ, який не побачить — це дуже просто допустити і забути за роботою. Тому і потрібен ПМ, щоб перевірити все по 5му разу і знайти помилки в комунікації и розподілу. І це не задача програміста, навіть якщо йому дають пряму комунікацію з замовником чи овнером.

Валентин, дякую за відповідь. Проте дійсно бачу що ми розмовляемо про зовсім різні речі, це дуже прикро — дійсно :( И як би ми були в одній команді, то я би спробував донести мої думки і бачення. Але давати якісь поради, сперечатися в інтренеті — це не для мене.
Всі помиляються — це норм, я помиляюся — це норм, @Stanyslav Semukhyn помиляется — це норм. Тому не хочу, і ще раз про це говорю — щоб всі сприймали мої меседжи як якісь звинувачення в сторону @Stanyslav Semukhyn.
Головне як людина сприймае помилки, як їх аналізуе (критичне мислення), як відокремлює свої помилки від помилок інших у таких речах як «колективна відповідальність», ну і звісно як людина змінюе себе. І в цьому я побачив ту проблему що змусила мене написити перший пост в цій темі.
Ну і головне — здатність з віком все ще сприймати нові знання і погляди: якщо якась людина пише щось незрозуміле, або те з чим ви повністю не згодні, але з тією людиною згодні купка людей, а ваше бачення скоріш поодинике — то може щось в тому є? Може то не повна маячня? Може треба почитати, спробувати зрозуміти, відкинути неприйняття?

Ну і головне — здатність з віком все ще сприймати нові знання і погляди:

«З віком»? Так, у вас професійно навчена здібність походячи обхамити. Якщо ви цього б не писали, ще були б шанси повірити в добри наміри і ваші всі ці поклони «не сприймайте як зауваження».
Але ви не втримались і показали своє нутро.

Може треба почитати, спробувати зрозуміти, відкинути неприйняття?

Спочатку — так і зробив. Зараз — ви втратили довіру. Вперті ентузіасти заслуговують уваги, але хами — ні, скільки ви б ні мовокрякали свої банальнощі.

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

Глобальний висновок з цього кейсу я зробив.
Якщо під час співбесіди менеджер/продакт оунер на запитання про процесс, планування та беклог відповідає якусь несенітницю або переводить розмову в емоційне русло — треба тікати від цього оферу як від прокаженого. Бо далі буде ситуація, яка описана в кейсі — ПО ігнорує будь-яке планування та документування і потім будь-який фейл девелопера перетворюється на катастрофу загально поектного значення і винуватцем назначать девелопера.

Наведені Вами принципи — це принципи менеджменту, а не програмування. Принципи програмування — це SOLID, DRY, KISS.
Тому програмісту рівнем нижче ліда краще просто шукати компанії, де якість менеджменту дозволяє йому зосередитись на технічних тасках.

Цілком згодний що для досвідченої людини це дійсно важливо які процесси в тому місці куди вас запрошують.
І це дійсно приниципи менеджменту, а не программування. Але цей топік і ваш кейс — він же не програмування. Ви написали «як БА і ПМ вчать программіста як йому робити свою роботу» — ні такого не було і приблизно. Ну і взагалі відчуваеться якась зневага... ну це популярна думка на ДОУ типа що- що функція ПМ замовляти піццу, а аналітики всякі — це дармоїди що мішають працювати розробникам.
Те що багато хто пише «ПМ повинен робити те, ПО робити те, а ми розробники тільки ось» — це абсолютно прийнятна нормальная практика, але це щось усереднене + типове для нашого місцевого аутсорсу. А гнучкі методологіі на те й гнучкі — що вони покривають більше варіантів і опцій.
Я пряцював в різними командами — маленькими, середніми, великими, з командами в різних конфугураціх — десь не було QA, десь PM/PO, десь BA/SA, десь не було спринтів, десь не було взагалі таск-менеджменту до якого ми звикли, десь процесси вже були, десь часто мінялись, десь їх не було майже — і у більшості це були нормальні команди і був результат. До речі я був колись розробником (досвід біля 7 роки) — тому я був «на тому боці барикади», і розумію біль розробників.
Сподіваюсь більш-менш порозумілися? :) А то раптом разом придеться працювати! :))))
Якщо вам і ще комусь цікаво — добре було окремий топік замутити — хто як розуміе процесси в розробці :)

Аналогічно, я за 7 років роботи програмістом пропрацював у різного калібра компаніях, різних командах з різними підходами та методологіями. І я дуже далекий від думки, що менеджери не потрібні. Сабжевий кейс дуже живо це демонструє — якби на проекті був менеджер, ця ситуація була б неможлива в принципі.
І я для себе вже давно зробив висновки, в яких командах та з яким розподілом обов’язків я можу ефективно працювати, а яких мені краще уникати. Ставати героєм розробки програмного забезпечення, який один, сам без менеджерів, документації та QA створить проривний продукт — такої задачі давно немає. Є чітке розуміння «контракту» що я можу зробити зі свого боку для проекту та за яких умов.
Для проекту з наведеного кейсу я можу зробити тільки одне — вчасно з нього втекти. Або, ще краще, на нього не потрапити.

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

Дякую всім за цікаві історії!

@Andriy Bas, щодо бурхливої реакції на пропозицію Discovery — у таких випадках допомагає правильне наповнення і подача цієї фази:
1) На виході має бути не лише серія воркшопів і гарна презентація, а також працюючий РОС або інтерактивний прототип, провалідований з юзерами (тобто tangible deliverables)
2) У замовника без досвіду назва «discovery» може викликати негативні асоціації — «вони за мої гроші хочуть розібратися в проекті! це має бути їх sales інвестиція!». Тому її можна змінити на щось типу POC / Architecture / Product Design Phase.

З іншого боку, якщо замовник аж так образився, то висока ймовірність що він і далі був би незадоволений критикою його ідей під час розробки, і міг просто не заплатити за роботу (частково або повністю). То може й на краще що ви розійшлися на ранній стадії ;)

Вітаю, Галина.
Дякую за рекомендацію.
Так, я теж гадаю що це й на краще що не продовжили співпрацю разом, зекономили собі нерви (і можливо кошти)!

Я и не спорю.
Не каждый разработчик способен хорошо делать проект без адекватного планирования. Я — не способен. И проблемы в этом не вижу.

Мне вполне достаточно уровня ответственности и уровня компенсации в моей должности. Я бы разве что, сменил страну проживания, не более.
Брать вершины и менять мир уже много лет как нет желания. Есть желание просто делать свою работу хорошо на своём уровне. И не более.

Залізна витримка нашого BA допомогла йому закінчити презентацію, попри це звукове тло.

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

Текст от Фоголя с запятыми. Не верю! :)

@Alex Fogol ++;
Классный пример как гибкость и отсутсвие агрессии — помогает достигать целей!

Я думаю это редактор расставил :)

52 запятые! Товарисчъ Фогол за всю свою жизнь столько запятых не написал! %)

это не к бобру! (к) (тм)

я думаю, что если товарисч Фогол выпускался бы из школы сейчас и надо было cдавать ЗНО, то он бы его не сдал бы ни в жизнь так как завалил бы диктант / переказ з Української мови :)

К примеру Твір на тему Тараса Шевченка вышел бы как-то так —

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

а шо так сразу «з украйинськойт мовы» шовинист да националпатриотист? ))

שבצ’נקו נולד בכפר בגוברניית קייב במשפחה של איכר - צמית של בעל אדמות מקומי. אימו נפטרה בשנת 1823 וכבר באותה שנה אביו התחתן שנית. אימו החורגת התייחסה לטאראס הצעיר בנוקשות והוא היה תחת השגחתה של אחותו. בשנת 1825 נפטר אביו והוא החל להתפרנס מעבודות מזדמנות שונות. בשנת 1829 הוא התחיל לשרת את בעל האחוזה, תחילה כעוזר טבח ולאחר מכן כעוזר כללי. בעל הבית ראה את משיכתו לציור ואישר לו ללמוד ציוד בווילנה. כאשר הם עברו לסנקט פטרבורג, הוא מסר את הנער להמשך לימודי ציור לאחד הציירים. בשנת 1836 במהלך שיעורי ציור בגן הקיץ הוא הכיר אמן אוקראיני ודרכו את אלכסיי ונציאנוב, קארל ברולוב וואסילי ז’וקובסקי. הם מיד ראו את הכישרון הגדול של הנער והיו מעוניינים לשחרר אותו מצמיתות. הדבר לא הלך בקלות כי הסכום שבעליו דרש תמורת זה היה גבוה מאוד. בסופו של דבר סוכם שקארל ברולוב יצייר דיוקן של ואסילי ז’וקובסקי שיימכר והסכום שהיה מוערך בכ-2500 רובל יועבר לבעליו של הנער תמורת שחרורו. הדבר נעשה ב-22 באפריל 1838. באותה שנה שבצ’נקו התחיל ללמוד באקדמיה לציור בסנקט פטרבורג.

Точек многовато.

Прочитал первую историю — исполнитель же сам виноват в том что не понял что от него хотят. И кстати сам этого еще не понял.

Просто нет понимания откуда берутся деньги на его зарплату

Лучше пускай такой заказчик оставит эти деньги себе.

В обязанности исполнителя не входит разгадывание ребусов и угадывание тайных желаний заказчика.
Адекватно поставить задачу и убедиться, что исполнитель правильно её понял — это задача того, кому нужен проект, кто осознаёт его бизнес-значение. Исполнителю проект интересен исключительно как полигон для обкатки своих технических подходов и наработок.
Ситуация, когда заказчик как беременная женщина хочет то мороженного, то морковки, исполнителю не интересна. А при нынешней ситуации на рынке исполнитель при таком стиле менеджмента сравнительно легко переходит на +1000$ туда, где заказчик точно знает что и зачем ему нужно, может адекватно поставить задачу и готов в любой момент всё разжевать исполнителю при малейшем недопонимании.

Підписатись на коментарі