На LinkedIn мне, как, думаю, и многим из вас, часто пишут. Чаще всего, это бывают либо рекрутеры низшего уровня, которые особо не вдаются в детали моей специализации и спамят просто «на удачу». Либо, это те, кто пытается предложить мне услуги, которые, ха-ха, я и сам предоставляю (всяческое R&D).
По ходу Жизни, мы развиваемся, у нас раскрывается определенное Мировоззрение и мы что то делаем в своей Жизни согласно нее.
В моем случае, мое Мировоззрение привело к тому, что я реализовываю один Проект через два Стартапа. Об этом Проекте и будет речь в этой статье.
Цель статьи:
собрать команду реализаторов Проекта;
продать часть доли Проекта;
Структура статьи:
введение
презентация
предложение
заключение
Дисклеймер:
Так как будет презентационная часть, то будет 8 картинок.
За год команда разработки Kaiten выросла в 3 раза, и привычные процессы перестали работать: доска переполнилась, потерялась прозрачность, а чтобы узнать, на каком этапе работа, приходится проваливаться в каждую карточку.
Вместе с Юрой Юрковым, Delivery Manager Kaiten, расскажем, как мы прошли путь трансформации, какие решения сработали и как не потерять управление в момент масштабирования. Если вы в похожей ситуации — читайте статью и используйте наш опыт, чтобы быстрее навести порядок.
При проектировании модели автоматизации бизнес-процессов проектируются модели самих процессов: вначале концептуальные, затем детализированные, в виде взаимодействий пользователя (или внешней ИТ системы) с проектируемой ИТ системой. Проектируются модели, взаимосвязывающие разные процессы:
связывающие по данным — модели логической структуры данных,
связывающие по пользовательским интерфейсам — модели переходов между интерфейсами.
Прошло целых два года, как команда NSR Specification твердо пообещала добиться автоматизации экспертизы цифровых информационных моделей (далее…)
Продолжаем цикл офигительных историй по мотивам интервью с Дмитрием Пищальниковым.
Предыдущие посты тут:
– (далее…)
Всем привет!
Эволюция специалиста из простого разработчика в тимлида в рамках небольшой компании зачастую является событием как желанным, так и немного тревожным. Новоиспеченный тимлид обычно знает про роли и обязанности вскользь, от коллег и из статей в интернете. В таких статьях тимлида могут описывать и как штатного психолога, и как переросшего себя ведущего разработчика, и как человека, который умеет всё и должен делать всё.
Поэтому здесь изложено видение роли тимлида, характерное для нашей компании — не слишком подробно, но с охватом самых важных моментов. Погнали!
Сегодня продолжаем разбираемся с запрещенкой в IT, и выясняем, что с ней не так.
Это часть вторая, первая часть находится вот тут (далее…)
10:00 — дейлик. 11:00 — синк по новой фиче. 13:00 — демо. 15:00 — созвон «на пару минут». 16:00 — еще один. 17:30 — ретро. 18:30 — теперь можно поработать.
