Як ви маєте справу з надмірними API / технологіями

Я думаю, що більшість людей опинилися в цій ситуації.

Починається початкове планування проекту. Викладені вимоги. Після архітектурного огляду та сортування за допомогою API / Frameworks вибирається технологія підгонки. Розробка починається.

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

Як вам вдається в цих ситуаціях? Ви ходите на хаки, чи досліджуєте далі, що ви скажете керівництву?

Прототип, прототип, прототип !!

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

Метт Raible (хлопець із порівняльної версії веб-версії Java) пропонує, якщо можливо, працювати з рамками протягом тижня.

Прототипування включає дослідження підтримки громади за рамками та іншими чинниками

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

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

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

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

"Як вам вдається в цих ситуаціях?". Що я бачив / переживав:

номер 1 бал Я згоден з Птолемеєм: будь чесний:

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

Є курси ІТ, які займаються лише такою ситуацією. Ви розміщені з акторами, і вони розміщують розлюченого клієнта, який чує цю новину. Ви отримуєте багато підказок навколо цього. Звучить нерозумно, але, ймовірно, тільки після цього ви помітите цінність цього. Я залишив аркуш з 80 пунктами, щоб запам'ятати в тих ситуаціях ... (і практиці).

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

- Інша справа може бути бічним мисленням: якщо цього неможливо зробити, спробуйте запропонувати щось зовсім інше, що забезпечує однакову цінність для замовника. Якщо технологія не працює ВСЕ / зламається / вискакує з угоди / тощо ... Якщо клієнт купує це, він може отримати те саме значення в кінці. Але доставити це теж досить важко. (для одних і зовсім не для інших). Для цього вам потрібні справді досвідчені хлопці. Аналогічна ситуація полягає в тому, що Технологія НЕ ВІДПОВІДАЄТЬСЯ ... це займає кілька місяців ... Тож вам потрібно переконати замовника перепланувати та прийняти перепланування та вплинути на його організацію ...

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

- Ще один засвоєний урок - це дозволити вашим архітектурним матеріалам проходити канали перевірки, особливо на великих проектах. Підпис може охоплювати вашу дупу. (збережіть усі ваші електронні листи LOL)