В чем секрет успешного интервью с заказчиком? Везение, контакт с клиентом, вовлеченность, простота, креативность? По наблюдениям Кирила Белявского, Lead Business Analyst, ключевой фактор успешного интервью — это хорошая подготовка. Как готовиться — детально в материале.
У статті ми поговоримо про естимацію тестування, оскільки це те, від чого залежить можливість проджект-менеджера ухвалювати правильні рішення щодо управління проєктом. З’ясуємо, з чого починати оцінювання завдань, щоб експертність QA-департаменту зростала.
Health-чек проєкту може бути актуальним для багатьох: від топменеджерів і власників бізнесу до будь-кого в компанії. Він допоможе краще оцінити якість сервісу на проєкті, виявити те, що можна поліпшити, та запобігти можливим ризикам. Як його проводити — у статті Юлії Сичкової, Head of Delivery у Fulcrum Rocks.
Есть ряд стандартных типов контрактов, и каждый из них может иметь различные варианты. Какие вопросы стоит задать, чтобы выбрать подходящий? Наталья Ренская, организационный консультант-коуч, создала детальную инструкцию с примерами.
Часто навіть технічним спеціалістам потрібна допомога в структуруванні проєкту та розкладанні усього по поличках. Можливо, багато з вас брали участь в оцінюванні проєкту і навіть мають певні tips&trics. Але завжди знайдуться нюанси, які можна випадково пропустити. У статті розглянемо проєкт під мікроскопом, зокрема його оцінювання.
Эта статья посвящена изменениям. Она построена на примере работы с системой управления проектами. Но некоторые примеры — из внедрения ТРИЗ и систем управления персоналом для больших предприятий. Полезно прочитать тем, кто уже работает над процессами, директорам, которые проводят изменения, и топ-менеджменту — для понимания принципов, из-за которых нововведения могут провалиться.
На этапе выявления требований закладывается фундамент будущего продукта, и от качества работы BA будет зависеть, насколько надежным он получится. Поэтому в первую очередь важно узнать, действительно ли то, что озвучивает заказчик, совпадает с реальной потребностью бизнеса.
У цій статті спробуємо розібратись, що таке soft skills, звідки вони беруться і як їх професійно оцінюють за допомогою спеціальних інструментів. Також з’ясуємо, чим оцінка може бути корисною для айтішника і чому компанії, які витрачаються на таку непопулярну річ, насправді дбають про своїх працівників.
Фейлят все — и большие компании с опытом, и маленькие «зеленые» фирмы. Не фейлить невозможно. Проваливать проект — это не плохо, плохо выходить из проекта, не взяв на себя ответственность. Артем Ганжа, СЕО iSKY.solutions, рассказывает о факторах, которые повышают вероятность фейла и что делать, когда что-то пошло не так.
Проблема невідповідності естимейтів фактично витраченому часу знайома чи не кожному менеджеру. Як наслідок — виснаження, демотивація та інші неприємності, з якими доводиться немало працювати. Хоч би ким ви були — розробниками, тестувальниками, менеджерами, зацікавленими в темі оцінки часу, — запрошуємо до прочитання.
Разработчик Руслан Дмитракович рассказывает, что у него возникла задача оценить группу программистов, работающих над проектом. Ситуация напоминала мультфильм «38 попугаев»: нужно измерить удава, но как это сделать — неизвестно. В результате появилась методика, которую он представляет в этой статье.
Проєктів без ризиків не буває, бувають лише неідентифіковані ризики. І з ризиками треба працювати, тільки якою мірою і за допомогою яких інструментів — залежить від ролі на проєкті, рівня занурення в проєкт, а також від стейкголдерів, з якими доводиться мати справу. Андрій Мудрий, що працює в ІТ-галузі майже 15 років, 10 з яких — у царині менеджменту, розповідає про керування ризиками.
Качественная оценка — необходимое, но недостаточное условие успеха. Следование лучшим практикам управления проектом и изменениями на всех его стадиях абсолютно необходимы. При этом хорошо выполненная и структурированная оценка может сильно помочь в последующих проектных активностях. Александр Катруша, Senior Engineering Manager, дает рекомендации по оценке трудоемкости проектов.
В первой части статьи Александра Катруши, Senior Engineering Manager, рассмотриваем основные сложности в оценке проектов, цели процесса оценки, требования к оценщику (разработчику), структуру и единицы измерения оценки.
Тема оценки проектов актуальна для многих проджект-менеджеров, которые сталкиваются с вопросами оценки задач, спринтов, релизов или разработки всего продукта. Наталья Ренская, Program Manager в Luxoft Ukraine, советует, как избежать головной боли (или хотя бы уменьшить ее) по поводу неправильных эстимейтов.
Більше 200 компаній протестували новий сервіс для оцінки проектів Quotify, що намагається конкурувати зі звичними Excel та Google-таблицями. У чому його переваги, які складнощі слід вирішити у найближчому майбутньому та як зреалізовано проект — розповідає Андрій Насипаний, Product Manager Quotify.
Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех). Я попробую изложить подход, который вы можете использовать, если обнаружите себя в подобной ситуации.
Рейтинг и грейд почти синонимы, точно также и эта статья очень близка к циклу предыдущих, в ней точно также затрагивается вопрос «какой разработчик должен получать больше?». И в то же время она стоит особо и люба мне особенно, так как в ней, помимо краткой характеристики родовых недостатков существующих систем грейдинга, есть много позитива.
Я знаю и умею или только так думаю? Как меня видят со стороны и как это совпадает с моим мнением? Каковы мои достоинства и недостатки? Каким меня видит моя команда, мои коллеги, мое начальство? Какие у меня перспективы, на что я могу рассчитывать?
Представляю широкому кругу читателей свои наработки по оцениванию, грейдингу, performance review и развитию персональных навыков.
По сути, объект, которым торгует программист — это человеческое внимание. Оценка трудоемкости и собственно программирование сходны меж собой в том смысле, что оба процесса представляют собой декомпозицию задачи на более мелкие части и привлечение внимания к каждой из этих частей; в случае программирования — подробное, с точностью до запятой, а в случае оценки — приблизительное, с точностью до подсчета элементарных пунктов в соответствии с выбранной детализацией.
Коментарі