Pull to refresh
17
0
Данил Никифоров @danilNik

Пользователь

Send message

Проектный Менеджер в IT. Обязанности без полномочий

Level of difficulty Medium
Reading time 7 min
Views 9.9K

Мне захотелось осмыслить свой опыт и те системные проблемы с которыми я сталкивался работая на позиции проектного менеджера (ПМа) в IT. Практически всегда я видел похожую картину - руководитель компании хотел передать часть ответственности линейному менеджменту, чтобы освободить себя для более стратегических задач. Поскольку работа в IT чаще всего проектная, найти ПМа кажется логичнее всего. Ищут человека, который не боится брать ответственность за проект целиком. При этом, остальные процессы в компании (инициация проекта, подписание контрактов) практически не меняются и остаются завязаны на ТОП менеджменте. В итоге к ПМу проект приходит на стадии, когда уже все решено: определена команда, выстроены ожидания заказчика, цель проекта, бюджет. И далее ПМ работает с тем что есть, не имея полномочий изменить состав команды, бюджет проекта, заказчика.

Но без делегирования полномочий не решается проблема загруженности ТОП менеджмента. Происходит интересная ситуация, когда есть человек “отвечающий” за проект, но все решения принимает ТОП менеджмент. Проблема становиться менее видимой, потому что “виноват” во всех принятых решениях ПМ. ПМ, как правило, ответственный человек, то он упорно ищет причины неудач в себе. В компании могут звучат красивые слова про то, что каждый может повлиять на ситуацию, у нас Lean, Agile и вот это все. Но это только мешает увидеть несоответствие обязанностей и полномочий.

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

Читать далее
Total votes 11: ↑9 and ↓2 +7
Comments 17

Социальная сеть без сервера. История разработки iOS-клиента и backend

Reading time 11 min
Views 22K

Интро


Я хочу рассказать об опыте разработки iOS-клиента для социальной сети и бэкенда реализованного с помощью BaaS Parse.com Нижe приведена архитектура, которая у нас получилась, некоторые tips&tricks и размышления по поводу работы с parse.com.
Изначально клиент думал о сервере на RoR, но, видимо, они не рискнули вкладывать сразу много денег. Мы подписали строгое NDA, поэтому ссылку на Appstore я дать не могу. По доброй традиции всех IT книг, хочу выразить благодарность заказчику Х и компании Y за то что мне довелось поработать над этим проектом и подчерпнуть весь этот опыт. Также спасибо А. за то, что написал часть про модуль для встроеных покупок.
Читать дальше
Total votes 17: ↑15 and ↓2 +13
Comments 27

Полезные факты о языке программирования Objective-C

Reading time 3 min
Views 23K
Я уже 2 года занимаюсь разработкой приложений под iOS и в этой статье мне захотелось представить те факты, которые показались мне интересными и полезными. Буду рад, если вы так же поделитесь своими знаниями в комментариях. В следующей статье хотелось бы собрать подобные факты о Foundation Kit.

.m


Расширение .m (message) ввели для того чтобы выделить ключевую особенность Objective-С. По сути, мы не вызываем методы у класса, мы отправляем сообщение объекту, после чего происходит диспетчеризация в ходе которой диспетчер методов Objective-C ищет нужный класс и вызывает у него необходимый метод.

NS


Префикс NS обозначает Next Step. Он возник еще в те времена, когда не было Cocoa, а фрейворк назывался NextSTEP и был продуктом NeXT Software. Apple купила эту компанию в 1996 году и чтобы не нарушать обратную совместимость кода продолжила использовать этот префикс.

Читать дальше →
Total votes 45: ↑30 and ↓15 +15
Comments 37

В помощь тем кто хочет начать разработку приложений для iOS

Reading time 4 min
Views 20K

Разработчик, кто он?



Для начала, надо понимать зону ответственности разработчика приложений и те роли, которые могут присутствовать в ходе всего процесса разработки. Лучше всего это понимание приходит после работы в команде, но все-таки немного теории. Роли примерно следующие:
  • Заказчик
  • Менеджер
  • Архитектор, старший разработчик
  • Разработчики
  • Дизайнер


Роли можно расписать более подробно – все зависит от сложности проекта и от наличия или отсутствия человеческих ресурсов.
Как это все работает. У заказчика появляется идея, он хочет ее воплотить жизнь. Возможно, он еще сам толком не представляет, чего хочет и может выговорить менеджеру только несколько слов. К примеру «iphone» и«карта моих ресторанов». После чего, задача менеджера составить с заказчиком максимально подробную спецификацию приложения. В спецификацию должна входить вся информация от поддерживаемых версиях операционной системы до зарисовок экранов. Вот пример зарисовок(wireframes, mockups) вместе с оценкой.
image

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

Tips and tricks



Читать дальше →
Total votes 27: ↑14 and ↓13 +1
Comments 6

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Date of birth
Registered
Activity

Specialization

Mobile Application Developer, Product Manager
Senior
From 300,000 ₽
Project management
Development management
Risks management
Kanban
Scrum
Agile
Building a team
Development of tech specifications
Project planning
PMBOK