В форумной полемике - все заправские управленцы, но у кого есть реальный опыт?

Реальный опыт в управлении разработкой ПО в малознакомой области?
Какое место в иерархии вы занимали? Есть ли у вас набор проверенных методик и собственно, откуда он у вас появился?

Интересны проекты от пяти программистов.

(115)
-- интерфейсов нет? о_0 давно?

O_o С самого начала.

http://msdn.microsoft.com/ru-ru/library/87d83y5b.aspx

Я не про GUI конечно.

(117)
--можно

Нельзя. Я не про БД продуктива, а про БД вообще.

(116) надзорная роль - это когда я смотрю в отчеты, которые кажут показатели процесса разработки и отклонения от нормы, а потом пишу что-то вроде: "Евгений, у тебя вот эти два ТЗ покраснели, сделай с ними что-то" или "Константин, в этом ТЗ ни описания изменений в спецификации нет, ни объекты метаданных не заполнены, я не согласую помещение, т.к. чо вы там менять собрались, я не понимаю". Прямо в процессе не участвую, только воздействую на отклонения.
Главная роль - это, когда я беру ТЗ на стадии, когда там только требования, и делаю вот эту вот магию, в результате которой у нас есть, что муйнуть на продуктив. При этом и лавры мои, и ответственность моя.

Результатом проектирования является, логическая модель - процессы, функции, объекты данных, профили, операции. Подробности тут http://v8.1c.ru/model/ можно пошукать

(119) к бд sql тоже доступов нет ни у кого. Есть некий тестовый инстанс MSSQL, к которому у некоторых есть доступ для тренировочно-исследовательских целей и всё.

(118) да нафиг в большинстве случаев интерфейсы не нужны. По моему опыту, единственное место, где лично мне бы пригодились полиморфизм и наследование - это те прожекты, в рамках которых надо в Документоборот добавлять свои бизнес процессы. Там реально можно в три слоя матом покрыться, пока заставишь свой процесс с комплексным работать. В остальном 1С - предметно-ориентированная среда, в которой ты уже говоришь на языке предметной области на столько, на сколько это вообще возможно и ни какой ООЯП тебе такой абстракции без фрэймворка не даст.

да и в документообороте это все так только потому, что там архитектура - гуано законченное. Когда храбрые парни из команды ДО в 1С вычистят эти конюшни, и тут надобность в интерфейсах отпадет.

Когда сам пишешь ПО - как-то редко заботишься о модульности, слабой связанности и т.п.

Когда тебе "доверяют" написать ПО объем поболее - ты с радостью кидешься грядкой на задачу и... И недоумеваешь, почему раньше у тебя одного всё получалось задорно и красиво, а вот эти 10 высокоплачиваемых спецов творят какую-то херню.

Ты вроде бы и развел по углам, но они все равно как-то смешивают понятия, делают не по проекту (я пробовал, у меня тормозило!).

Паттерн IoC на самом деле оченно помогает держать прогов на расстоянии, каждый может заниматься только своим модулем.

Плюс, механизмы сборок, пространств имен - могут запросто закрыть доступ прогам к тем модулям, куда им соваться по дизайну нельзя.

Качество контроля на другом уровне. Прогу просто тяжело сделать ошибку. Да что там контроля - качество распределения работ! Любой прог может сделать модуль, не имея понятия - что происходит в других модулях и чему служит его модель.

В 1С это реализуемо путем бесконечных соглашений.

(120)
-- Подробности тут http://v8.1c.ru/model/ можно пошукать

Ты в этой конфе работаешь?

(122) ни одно правило, которое не контролируется системой и не может быть ей запрещено, не работает. Так что хоть засоглашайся - обеспечивать тебе все эти профиты один хрен руками придется

(123) ну... когда она была взята из коробки с надписью СППР, да

(120)
-- к бд sql тоже доступов нет ни у кого.

)))

В 1С ты в ПРИНЦИПЕ никуда за пределы DAL не выходишь.
Я об этом говорю.

(124)

В 1С - да.

+(124) "и не может быть ей запрещено" = "и противоречащие этому правилу действия не могут быть запрещены системой"

(120)
Когда ты выполняешь надзорную роль - кто пишет ТЗ, которые "покраснели"?

Кто составляет ФТ на основе которых пишутся ТЗ?

На основе чего составляются ФТ?

(126) и СЛАВА БОГУ! Потому, что высокооплачиваемые специалисты могут обрушить чудовищный огненный дождь на головы несчастных пользователей. Прочие же специалисты могут намного больше дамага нанести, дай им доступ. Так что я только счастлив, что хотя бы дропнуть ни кто ни чего не может...

(129) ФТ пишут аналитики (они, правда по-другому называются). Другое подразделение. На основании чего - я в дшэ ни бубу, но думаю, что должны - на основании полного и законченного описания модели бизнес процессов компании.

Когда я выполняю эту роль, я всегда начинаю с определения объекта автоматизации (процессов то есть), цели автоматизации и требований к объекту.

Ощущение от ветки такое, будто вчерашний студент-теоретик, нахватавшись отрывков каких-то "умных книг" из серии "как надо жить for dummers", пытается троллить мужиков-практиков, которые не одного коммерческого директора пережили и главбухов пачками едят на завтрак голыми руками…

(133)
Это ты мисту делал?

(133)
-- которые не одного коммерческого директора пережили и главбухов пачками едят на завтрак

В ветке разговор о разработке ПО.

А не про то, как круто 1С-ник притерся в торговой фирмочке, которая всё IT отдала ему на откуп, платит ему сотку и горя не знает.

Разные вещи.

(133)
Сколько проектов ты запустил/завалил, Asmody?

(136) мне было 22, когда я, в должности главного специалиста одной подправительственой структуры, руководил разработкой небольшой учетной системы масштаба области. Система проработала 2 года, основные задачи решала, потом была заменена на другую, уже без меня. С тех пор я стараюсь, по возможности, не иметь дел с госструктурами.

(134) мисту делал Волшебник, я ее только поддерживаю

... и мочалок командир!

(137)
Не знаю, что такое масштаб области. Не знаю - зачем ты вообще про него упомянул. Если в рамках моего вопроса - у тебя один успешный проект, который ты запустил в 22 года?

У меня подошел к концу один проект. Проблема в том, что он оказался гораздо крупнее и сложнее, чем те, с которыми я имел дело до этого. Сначала так не казалось. Да и сейчас - смешанные чувства.

Так что с наскоку брать такие крепости больше не хочется.

"С наскоку" - это не только "открываем конфигуратор - погнали!", а и "ну, теперь то всё будем делать по ТЗ!!"

Хочется ЭФФЕКТИВНО делать вещи, усилиями классных НЕСКОЛЬКИХ спецов. Ибо я верю, что то, что может выйти из под рук такой "команды" - заведомо превосходит результат работы одиночки.

(140) так ты медаль хочешь? Ну так с этого бы и начал, а то не зайди Asmody, до ночи бы до сути не добрались...

-- так ты медаль хочешь?

Какую медаль??

(141)
Да как с тобой до сути то добраться? )))

Роли: главная, надзорная и... И народ.

ФТ пишут аналитики, ТЗ - так и непонятно кто.

Интерфейсы не нужны, а программисты доступа к БД не имеют.

Конечно, сложно будет...

(140) а ты разве священник, чтоб я перед тобой исповедовался?

(138) И делал я её, кстати, с нулевыми знаниями PHP и MySQL, хотя программирование вообще, конечно, знал, и языком запросов владел.

Свой первый большой проект я реализовал в 1997-1998 году, это была конфигурация с нуля для расчёта зарплаты в строительной фирме. Там был полный набор всех видов расчётов, включая прогрессивный подоходный налог, всевозможные льготы, расчёт по среднему, налог с матвыгоды и прочая фигня + полный набор отчётности в налоговые органы, включая электронную.

(145)+ Т.е. это всё было в мои 18 лет и когда я стал совершеннолетним, я уже был руководителем проекта. Считай, родился.

И по теме ветки: вот это моё творение http://1c.ru/news/info.jsp?id=4499 (точнее, творение группы товарищей под моим руководством)

(0) Сколько работаю, только один раз видел человека с профессиональным подходом к разработке базы данных. Чел был архитектором и использовал профессиональные средства моделирования баз данных.
Пока не была создана модель базы данных, никто не писал ни строчки кода.

Получается, что все остальные - не профессионалы.

(144)
Так ты ж сам начал. o_O

(148)
Ну... Ведь проектирование БД != проектирование всего ПО.

(147) А вот моё http://1c.ru/news/info.jsp?id=1114

(150) разработка баз данных на одинес, в подавляющем большинстве случаев, сводится к подавляющему отсутствию документации, отсутствию модели ПО и разработка осуществляется по принципу "куда нелегкая вынесет"

(150) если вы хотите разработать серьезное ПО (не базу данных) то вы не на тот форум пришли :-)
Здесь ни разу не поднималась тема об использовании в работе профессиональных средств моделирования.

(0) "Реальный опыт в управлении разработкой ПО в малознакомой области? "

Тут нет таких специалистов, имхо.

(153) поднимались. И копья ломались только так. Только в случае с 1С, весь этот шум вокруг CASE-средств — не более, чем пук в лужу.

считаю, что поднять можно любой проект, главное - правильно выстроить отношения с персоналом и с самим собой
например, известная притча о Майкрософт ворд
как известно, сроки и бюджет увеличились в 5 раз
был бы другой заказчик, а не Билли - слил бы проект в утиль
и не знали бы мы никакого Майкрософт оффиса
а так - пошли на уступки, не стали увольнять, в итоге - лучший офисный пакет в мире, жирная статья ежегодных доходов

поэтому иногда фейл это вин, а вин предтеча фейла
http://habrahabr.ru/post/145960/
ждём результаты по доминикане

(155)+ из свежего
v8: 1C + Case средства
Посоветуйте CASE TOOL для описания бизнес-процессов

(156)
(про Ворд) - фига се! O_O

(155) хорошо, что пару раз поднималась :-)
Потому одинес и не может выйти ни на один серьезный уровень.
Начисто отсутствуют в области одинеса специалисты, способные построить и презентовать модель, прежде чем приступить к непосредственной разработке. Все сводится к "мы ее слепили из того что было"

(160) да модель нарисовать — дело несложное, хоть и небыстрое и утомительное. Только практического толку от этих моделей и презентаций мало

(161) думаешь, в гугле и майкрософте тоже сначала кодируют, а потом думают? :-)

(161)
-- да модель нарисовать — дело несложное

Ну если речь идет о "товары на складах" - тогда да.

(161) это смотря, с какой целью рисовать. Если для презентации, то это действительно не имеет смысла

(162) в приложении к разработке на 1С толку от таких моделей мало

(163) ты пробовал реализовать складскую логистику с планированием размещения? или, например, расчет потребностей?

(166)
Сэр, нет, сэр!

Мне вдвойне теплее от того, что "расчет потребностей" херачится сразу синим кодом, сэр!

(164) вот тут http://mista.ru/dot/ похоронена старая волшебная статья. там, в том числе, есть схемы на основе структуры из первой УПП. много ли в них толку?

(163) Когда понятия не имеют, что\как делать - начинают заниматься рисованием и рисуют до потери сознания ибо пока ты рисуешь с тебя взятки гладки - благо фигней можно страдать бесконечно (удобно однако)

(167) кстати, "расчет потребностей" - чистая математика. рисовать там "модель"?

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

(171) ты пытаешься мне доказать, что ты умнее? ОК, ты - умнее. надеюсь, тебе полегчало, и сегодня ты будешь спокойно спать

(172)
С чего это он умнее?

Пускай предъявит послужной список.
Сколько коммерческих пережил и сколько съел главбухов на завтрак.

Там и посмотрим.

Ггнать пургу на уровне ТС вообще без проблем, решать реальные задачи на порядок сложнее.

Видел малознакомых с областью управленцев - смысла в такой работе не увидел, что-то вроде секретарши для разработчика.

(172) я вообще считаю, что на мисте умных людей нет. Умные люди по ночам на мисте не сидят.

Даже те, кто с мисты в мелкие бузинесы САМ выбился - ни фига не умные, просто коммерческая жилка развита и решимости больше.

(176)
Ну вот. Приложил.

По секрету - тут пол Мисты из Штатов посты ирачит.

(178) да хоть из Гондураса. Это не показатель ума.

(178) Кстати, тоже недавно из штатов Постил, анонимайзеры быстрые :-)

(175) Видел знакомых с областью программеров. Научить программировать по ТЗ можно и обезьяну, а вот думать за обезьяну-нужно уметь ;-)

(179)
--да хоть из Гондураса. Это не показатель ума.

Разные часовые пояса, smart one. ))

(182) мне статистика по ипишникам недоступна, так что можно только догадываться...

(0) 1C Lead Software Engineer -- 6 лет
Senior Test Automation Engineer -- 3 года, заход сделан на Lead

Думаю, что могу. Если учитывать, что разработка софта -- многограный процесс. И нужны не тоько кодеры, но и другие члены команды

+1

Все ж таки не совсем ясно, что нужно автору :)

Тут вопросы и про архитектуру - это к проектировщикам-архитекторам.
И про набор людей в команды и управление ими - читай ДеМарко и Спольски. Это уже к РП.
И про бюджеты, про риски, про стандарты, кейсы и т. п.  )))


Начинай с команды - все пишут, что это самое главное. На хабре хорошее интервью было с авторами 500px. Наши соотечественники, проект в Канаде. Пишут, что сперва ничо не взлетело. Сели, подумали. Всех разогнали, набрали очень тщательно заново. Дело пошло.

Спольски пишет тоже самое - очень тщательно отбирайте людей.

Митник пишет, что на работу берет людей только умнее себя - только так можно самому научится и научить остальных новому.

И т.д.

(186)
Про архитектуру - вопросы только в разрезе 1С. И это - каким образом люди выражают архитектуру в 1С.

--И про бюджеты, про риски, про стандарты, кейсы и т. п.
Не было вопросов. Если только в общей полемике.


--Начинай с команды - все пишут, что это самое главное.

***. Всё?

Когда мне делали ремонт в квартире - была бригада. Была список работ. Я знал - кто конкретно какую работу будет делать. Я знал, кто за рабочими будет следить. На часть работ я понимал, что будет в итоге; на часть - не понимал, полагался на прораба.

У здешнего люда я спрашиваю -

1. Какими скиллами должны обладать люди В ИХ КОМАНДАХ
2. Как эти скиллы называются; как люди комбинируют эти скиллы (если комбинируют)
3. Что на входе у этих людей; (Вид информации, её подача)
4. Что на выходе (Вид информации, её подача)

Самое вменяемое, что я услышал - это про главную и надзорную роль. Что архитектуры как таковой нет, максимум - она описана в каком-то документе, который все должны соблюдать.

romansun, если вам непонятно, что нужно автору, может вам просто непонятен контекст обсуждения? Ну скажем, полный цикл разработки ПО в незнакомой области?

В этом нет ничего страшного, просто тутошний люд считает, что познал всё, а всё что непонятно - ересь и блажь. Успешность вон меряется пережитыми коммерческими дирами.

Телеги про то, что надо набрать команду, а архитектор должен создать архитектуру, а ТЗ должно появится само собой во всей этой заварухе - неинтересны, уж пардон за извинение.

(181) Видел кучу работы на которое ТЗ написать нереально, ну кроме "расширить, углубить (с)". ТЗ возникало по ходу работы и никак иначе. Реверс-инжиниринг например никто кроме порграммеров сделать нормально не сможет, причем делать его приходилось по ходу параллельной работы выявляя расхождения. А такой работы с 1С - вагон и маленькая тележка.

гемор

отвечаю по делу

>>1. Какими скиллами должны обладать люди В ИХ КОМАНДАХ

я набирал прежде всего толковых. Тестовых задач не давал, дебильных вопросов не задавал. Беседовал за прежний опыт, спрашивал, чего больше хочется (аналитика или разработка). Просил присылать примеры разработаных документов (ТЗ и прочих). На наличие сертификатов _смотрел_, но не придирался ))

Кого бы еще взял - грамотных и толковых людей на позиции архитекторов.

>>2. Как эти скиллы называются; как люди комбинируют эти скиллы (если комбинируют)

большей частью девушки - крен в аналитику. Но и программирование на уровне спеца по платформе. Ребята получились больше разработчики со способностями копать в пограничных областях с 1С разработкой.

Была возможность поработать с аналитиками не из 1С мира. Более, скорее всего, не буду. Весьма трудоёмко выходит. Многого не знают.

>>3. Что на входе у этих людей; (Вид информации, её подача)

Ммм.. у аналитиков - тонна разноплановой инфы - почта, телефон, эксели всякие, переговоры, всякие разные базы данных и прочее

У программеров, соответственно - структурированная конктретная инфа уровня ТЗ (не путать с ТП!) и постоянная поддержка разработки со стороны аналитиков. Да и аналитики могут и сами покодить что-нить несложное.


>>4. Что на выходе (Вид информации, её подача)

Зависит от проекта и документационного набора заказчика. Где-то ЧТЗ всякие, где-то СТП, везде ПМИ (программа и методики испытаний). Рук-ва всякие. От программеров - программы )) Тестирования нагрузочные могут быть.

>>Ну скажем, полный цикл разработки ПО в незнакомой области?

В любом случае в команде должны быть аналитики, понимающие предметную область.

Если они на уровне - то суперское знание РП предметной области не так критично.

По больше части, всё что делает РП  - это постоянно мониторит общую картину и дополнительными усилиями проталкивает забуксовавшие моменты. Плюс администрирование - бумажки всякие, переговры, протоколы, планы и прочее.

Соответственно, если люди окружают РП грамотные - то они сами постоянно на связи - где что проблемы, сразу говорят.

(191) А теперь представим что РП совсем не владеет предметной областью:
С позиции аналитиков - нечто тупое ходит и пытается командовать и ставить задачи по "глупым" шаблонам (типовым, РП не сможет их адаптировать под конкретный проект).
Вот и остаются функции секретутки с первого взгляда, да поддалкивателя не замо куда тоже.
А вообще в ваших речах хоть реальный опыт виден.

(0) А почему нет самого главного пункта: Я обучался менеджменту ИТ проектов.
Если есть методология, то можно управлять... Если проблемы с руководством людьми, замом берется сотрудник, обладающий харизмой в коллективе...
Для решения оргвопросов есть "меценат проекта" ит.д.

(193)
А где этому учат?

(193)
Я надеялся, что это "всплывет" в ходе обсуждения.

-- Есть ли у вас набор проверенных методик и собственно, откуда он у вас появился?

Как показывает практика - на мисте людей, прошедших специальное обучение - нет.

(192) гы

Так, коллега, авторитет :). То, что зарабатывается годами и далее по тексту. Нет уважения коллег, нет харизмы - управлять людЯми сложно.

Я вообще предпочитаю формулировку "координировать", а не "управлять". По умолчанию я предполагаю, что коллеги - крутые парняги в любом случае. И каждый занимается своим делом - кто-то кодит, кто-то аналитик и т.п. А кто-то читает бесконечную переписку и ездит по встречам.

Вот, скажем, уже руководитель РП, наверн, тот больше именно управляет - деятельность более формальная и административная. Дальше - хз, дальше я не гляжу. )))

(195)  методик чего, опять же? Управления людьми?

Я обучение не проходил. Читаю книжки всякие, статьи, на хабре есть прям список книг must have для руководства разработки ПО

Изучал 1С:Профкейс-это наш ответ pmbok, по сути. Сам pmbok читал чутка :) коллеги вот pmi сдавали...

(191)
Как вы описываете предметную область?

(192)
--нечто тупое ходит и пытается командовать
Нечто тупое вообще-то зарплатным фондом распоряжается.

!:-)

200

(192) Был проект по ЗУПу, зуп- на тот момент я его вообще не знал, пошел к руку- выторговал себе классного спеца, обрисовал задачу спецу, дал контакты. План работ, осметил его, накинул еще 30%, пошел защитил бюджет перед заказчиком, сделав им скидку в 10%, Далее каждые 2 недели сидел на совещании, косяков не было, но решили отжать по деньгам ибо проект выполнен спецом был ранее.


Вобщем мое мнение-классный рп не тот который мегакодит, не тот который профи в бух учете, бюджетировании или еще каком учете, РП - делает твою работу комфортной.

Как сказал мне один РП- я был в его команде

Крендель- не работай с идиотами (с)

Дешевле работать всегда с профессионалами своего дела, подбор и командообразование - вот функции РП.

Опять же если мы не говорим об рп на проекте в 10 пользователей

(201)
--РП - делает твою работу комфортной.

Ты ставишь центр оценки на место разработчика. Естественно, если ты разработчик, и тебе комфортно работать с РП - то это просто супер.

Вопрос в том, что должен делать РП, чтобы разраб думал, что ему комфортно.

(198)  как описывается предметная область - если кратко, на каждый бизнес-процесс рисуется блок-схема, шаги нумеруются, ниже приводится таблица с описанием каждого шага.

(202) РП должен создать условия для комфортной работы команды - вплоть до чая, кофе и печенек. Понятно, я утрирую, но у хорошего РП команда работает как-бы сама и со стороны всего процесса кажется, что РП только слоняется и ничего не делает )))

(203)
Нескромно, а можно пример?

(204) >>и со стороны всего процесса кажется, что РП только слоняется и ничего не делает )))

Не кажется а так и есть :) Хорошим разработчикам пастух не нужен.

+ (205) а еще лучше пример того, что было написано с подобным стилем разработки.

(206) >Не кажется а так и есть :) Хорошим разработчикам пастух не нужен.
Очень во многом согласен. Странно мне было учить РП предметной области. Если разработчиков енсколько - то возможно оно и надо координировать, а если речь об одном ответственном, то смысла в этом нет. Даже грамотные РП с десятком проектов просот сидят на работе и делают вид что очень заняты. Пяток звонков с клиентами в неделю в поисках ответственных и согласовании сроков за работу не считаю.

(207)
Десяток проектов - это высший пилотаж. Скорее всего - вы были свидетелями проектов пущенных на самотек. Там РП для галочки - он ничего не привносит в свои проекты.

(206) (207) (208)

)))

ох... понятно, что есть такие места, где роль РП, как бы это помягше сказать.. Но мы же не о них говорит, так ведь?

Далее, понятно, что на одного разраба один РП - странноватая схема. Хотя имеет место быть - если у такого РП десяток таких проектиков, и он просто консолидирует некий общий управленческий поток инфы для уже своего руководства. Ну, в таком случае, РП вообще не лезет в дела разработчика, он только регулярно узнаёт статус работ и помогает с какими-то организационными проблемами.


Тема сама и я говорю о реальных активных живых программных проектах, где задействованы на фултайм, скажем, 5-10 аналитико-разработчиков.
Им жизненно необходим координатор. Причем уже на 10 человек одного РП не хватает - как минимум нужен архитектор. В каждой миникоманде (2-3 чел) нужен свой лидер.

Приведу пример - в проекте участвуют несколько сторон (один заказчик и пара-тройка подрядчиков). С каждой стороны РП. С некоторых еще и архитекторы. Эти люди генерят только между собой письмо-поток до 30 штук в день. Наш герой-РП должен быть в курсе всего этого - читать, вникать, отвечать.
Плюс переписка уже со своими сотрудниками.. Вот и получается, что сидит РП и только и перепиской полдня занимается :)

(0) есть опыт на позиции от ведущего программиста тире архитектора до руководителя\лидера проекта.

используемые методики:
проектирование - экспертное мнение архитектора;
планирование - пмбок (частично).

требования к квалификации: сильный скилл аналитика плюс хорошее знание предметной области для РП as a must.
остальное - может варьироваться.

опыта управления разработкой ПО _в малознакомой области_ нет, и откажусь, если будут предложения.
возможность компенсировать какой то супер методикой отсутствие знаний предметки у РП считаю мифом.

(210)
--проектирование - экспертное мнение архитектора;

В чем проектируете?

(209)
Как-то размыто всё получается.

"как минимум архитектор"...
"5-10 аналитико-разработчиков" - я понимаю, что в 1С это way-to-go, в большом ПО, имхо, это дорога в хаос.

"Эти люди генерят только между собой письмо-поток до 30 штук в день."

Реально не понимаю - что там писать? На этапе согласования архитектур и технологий - да, возможно. Во время разработки - что??

Экстраполируя на "постройка дома":
- Майк, сколько у нас вообще этажей??
- Джон, не знаю, вроде 50!
- Но высотный регламент не позволяет строить выще 25-ти этажей?!
- У меня в проекте 50. Что делаем?
- Строим два раза по 25!
- Парни, у меня лифтовое оборудование заказано только на 10 этажей, больше поставщик не может.
- Строим без лифтов!

+(212) не надо про лифчики.

(211) где оформляем? визио, эксель.

(212)
Что писать? Издеваетесь??

Постоянное уточнение вопросов по:
Бюджеты
Сроки
Статус-отчеты работ
План-графики
Согласование встреч
Протоколы
Документация
Подключение техн. Спецов к перерписке по субвопросам, обсуждение, решение нужны ли встречи
Объемы работ
Пояснения, что входит в бюджеты и объемы и зачем это нужно
Жалобы
Ругань
Различного рода требования - ответов на столетние вопросы, требования встреч, требования документов

И тд тп тд тп

Не отвечаешь в почте - идут звонки и смс-ки

:)

(215) Что ты хочешь от ларька на 3 пользователя, там нету всего этого

Помните, как позиционировали себя БлэкБерри? Типа мы все такие корпоративные и деловые. Нащи телефоны для деловых и крутых бизнесменов. У нас офигительно удобная почта и нормальные настоящие кнопки, чтоб удобно писать.

Вот это все оттуда - почта отнимает порой по 70 % времени в день. Поневоле будешь думать о кнопках ))))