×Закрыть

Материалы по теме «management»

RSS

Коли цінності компанії не відповідають твоїм. Історія HR, що пройшла через вигорання Коли цінності компанії не відповідають твоїм. Історія HR, що пройшла через вигорання

Ilona Hromliuk 8408

30-річна Анна (анонімність збережена) майже два роки працювала ейчаркою в одній із львівських ІТ-компаній, звідки вирішила звільнитись через вигорання. Цінності компанії не відповідали очікуваним, і робота перетворилась на стрес. Дівчина розповіла про конфлікти з менеджментом, особливості професії, а також те, як розпізнати токсичного СЕО. 29

Как успешно сформировать команду и перейти к продуктивной работе Как успешно сформировать команду и перейти к продуктивной работе

Kseniya Leshchenko 6141

Чтобы достичь желаемой продуктивности и результативности, нужно понимать механизм формирования и развития команды, чтобы получать наибольшую выгоду для всех участников на каждой стадии развития. О том, как этого достичь — в статье Ксении Лещенко, Project Manager в Astound Commerce. 27

3 місяці роботи з дому. 5 порад, що пішли до смітничка 3 місяці роботи з дому. 5 порад, що пішли до смітничка

Pavlo Kostenko 26460

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

Зустріч 1:1 на ремоуті: як налагодити процес Зустріч 1:1 на ремоуті: як налагодити процес

Andriy Bas 6383

У дистанційних командах 1:1 — це чи не єдина можливість для менеджера та працівника зустрітися сам на сам у спокійній атмосфері. Такі зустрічі — не просто адміністративне питання, щоб вибрати софт для відеодзвінків та узгодити, де вести нотатки та завдання. Це ширше поняття. Що воно охоплює, для чого потрібне та як використовувати ефективно — у статті Андрія Баса, співзасновника Uptech. 12

Как работать с западными клиентами и не оплошать. 5 примеров из практики HR Как работать с западными клиентами и не оплошать. 5 примеров из практики HR

Tatiana Boichenko 7518

К каждому клиенту можно найти ключик. Ниже — 5 кейсов из моей практики о том, как найти его, если клиент за рубежом, а команда — в Украине. Этот материал особенно пригодится тем, кто работает с международными заказчиками, но не понимает, почему не получается строить долгосрочные отношения. А также тем, кто никак не может понять запросы этих «западных» заказчиков. 16

Пасивні агресори, жертви та критикани. Як виявити токсичного колегу та що з ним робити Пасивні агресори, жертви та критикани. Як виявити токсичного колегу та що з ним робити

Olga Kolpakova 27774

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

Jira на максималках: как автоматизировать рекрутинг, замер узнаваемости, финансовые процессы и учет доменов Jira на максималках: как автоматизировать рекрутинг, замер узнаваемости, финансовые процессы и учет доменов

Alekseii Okhmush 6112

Практически все процессы в Boosta настроили в Jira. Автоматизация помогла упростить трекинг задач, отслеживание прогресса, оптимизацию ресурсов и распределение ролей. Алексей Охмуш, Jira Administrator Boosta, делится опытом максимально широкого использования возможностей Jira и успешной имплементации ее практически во все процессы компании. 11

6 типів програмістів, які дратують менеджера 6 типів програмістів, які дратують менеджера

Ivan Ovcharenko 34923

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

Как мы перешли на удаленку и настроили процессы. 17 советов из опыта Как мы перешли на удаленку и настроили процессы. 17 советов из опыта

Vadym Ovcharenko 15488

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

Чому команди прохлопують свої естимейти Чому команди прохлопують свої естимейти

Olha Chmyr 12394

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

Как подружить разработчика и менеджера Как подружить разработчика и менеджера

Kostiantyn Mrachko 11049

Все компании, а тем более проекты, разные: отличаются задачи, подходы и команды. Их объединяет лишь одно — напряженность между менеджерами и разработчиками. Давайте взглянем на ситуацию и попробуем копнуть тему глубже, чем «технари против гуманитариев» или «исполнитель против руководителя». А разобравшись, подумать, стоит оно того или нет. 42

5 ошибок при внедрении OKR 5 ошибок при внедрении OKR

Константин Коптелов 12513

ИТ-компании ищут фреймворк для того, чтобы измерять и управлять. И находят два подхода: традиционный KPI и более гибкий OKR. Константин Коптелов, Business Development and Strategy Manager, рассказывает о возможных ошибках при внедрении OKR и как их избежать. 165

Комментарии

По крайней мере во всяких Датабриксах и тд — Solution Architect Потому что это звучит лучше чем «пресейлс инженер». А роль солюшн архитектора там выполняют «принсипл инженеры» (или типа того)
Сучасний принцип Мартіна вимагає використання абстрактних типів (інтерфейсів) і збереження контракту класу, а не його коду. А яка принципова різниця? Контракт теж може змінюватись під нові потреби, якщо щось у старому починає бути неадекватним.
По крайней мере во всяких Датабриксах и тд — Solution Architect это англоязычный джун/миддл, который всеми силами пытается тебе впарить их «самый лучший» продукт.
архітектурні драйвери Не зовсім зрозуміло, що це таке, можете пояснити?
архітектурні драйвери Не зовсім зрозуміло, що це таке, можете пояснити? зрозуміти суть проблеми, зібрати у замовників З такими обов’язками особисто я стикався на 100% своїх проектів.
Ну как студент что учился у вас в универе могу сказать что взятки почти на всех предмета. Уровень квалификации преподователей нулевой ( за искулючение пары прекрасных педагогов).
Хотілося б почути чи дійсно ви, як архітектор, займаєтесь System Design Это зависит от компании/проекта. В некоторых детальный System Design может быть задачей лида, а у архитектора очень высокоуровневый.
Спасибо, я постараюсь это учитывать в будущих статьях. С концовкой есть одна загвоздка — happy end бывает только у инвесторов, а у разработки концовка всегда одна.
хороша ідея, спробую описати у окремій статті. Вибачте, що не вдалось це зробити в цій — фокус був на інші речі
так, обидва — не наукові терміни, але функціональні вимоги — надто довго
Так я займаюсь як архітектор системним дизайном, але суттєва цікавий нюанси роботи архіртектора в тому, що перед тим, як створити/мотифікувати дизайн треба зрозуміти суть проблеми, зібрати у замовників архітектурні драйвери, а вже потім будувати системний...
Кожен, хто мав досвід співбесід у Фаанги, знає чи хоча б чув, що таке System Design. Поправте мене, але я десь ± уявляю собі роботу архітектора як людини, що створює/модифікує цей дизайн для конкретної аплікухи чи великої системи з багатьма аплікухами.
Я б додав до описаних технік — розвинути навик і звичку посидіти в тиші, розслабивши максимально всі м’язи і уповільнивши дихання, з закритими очима 10-20 хвилин 2-3 рази на день.
Отличная статья, правда резко оборвалась. По прочтению осталось чувство незавершённости)
щодо принципу Open/Closed: Ви пишете, що код класу має залишатись незмінним. Власне, це вимога застарілого принципу Меєра, щоб спростити і пришвидшити внесення змін в умовах, коли неможливі належні тестування і перевірка.