Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Galogen

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »
4846
"Ангел-хоронитель" уже подзае, если честно.
Фи, Денис, как грубо :-)
А вообще нужно быстро решаться на переезд! Думаю переезд уже давно состоялся бы, если мы имели коллективную финансовую ответственность за него. Правда в сравнении с суммами, которые народ тратит, содержание сайта не так обременительно, но может имеет смысл переходить в ВИП зону или близкую к ней?
Соотвественно менять провайдера. Поскольку эдак недели другая такой работы - и всех посетителей и т.п. мы просто фактически растеряем

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

Не могу согласиться с примером. В данном случае речь идет не о системе и надсистеме, а об объекте управления и системе управления. Последняя должна удовлетворять принципу Эшби. это очевидно, но система управления не является надсистемой или суперсистемой (поскольку именно такой смысл скрывается под "над" в описании автора)

Цитировать
Второй случай исходно несет гораздо меньше определенности, так как технология использования разрабатываемой ИТ системы неизвестна. При разработке системы предстоит разработать как организационный регламент, так и средства, которые его поддерживают. К таким системам относится большинство ИТ систем для групповой работы: учетные, документооборотные, CRM, PLM и т.д.
Не понятна логика выводов. Любой проект, а тем более инновационный (а ИТ проект как мне думается и относится к таковым, то есть венчурным связанным с риском), подразумевает вопросы организации, выбора средств и т.п.
Мне не ясно из статьи в чем разница системного происхождения цели и проблемного, и почему они противопоставляются?

Цитировать
если кроме создания ПО не планировалось больше ничего - это принципиальная ошибка создателей сайта
Это камень в известный мне огород?  ;)

Цитировать
Для того, чтобы не нести бремя этого риска самостоятельно любой исполнитель, чем бы он не зарабатывал себе на жизнь, ДОЛЖЕН УМЕТЬ ФОРМАЛИЗОВЫВАТЬ И ФИКСИРОВАТЬ НА БУМАГЕ ЦЕЛИ, относящиеся к его обласи компетенции, ВЫБИВАТЬ ПОДПИСЬ ЗАКАЗЧИКА под этими целями и ПРИТЯГИВАТЬ ЗА ЯЗЫК в случае попытки нагрузить избыточной ответственностью за чужие просчеты.
Может легче государство поменять, а лучше Галактику :)

Что удручает, это отсутствие вообще ссылок на мировой опыт в виде ссылок на книги, статьи, тезися докладов и т.п. Вернее оно присутствует, но пренебрегается явным цитированием и указанием первоисточников..

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

В общем статья создает двойственное впечатление. Начало както не гармонизируется с концом. Начали с понятия цели, кончили концепцией.

Мне кажется, статья должна быть образцом целепостановки и целедостижения. Т.е. нужно поставить цели статьи - чтобы они были понятны и соответстовали СМАРТ, а также были показаны результаты - достигли ли мы цели или нет, в чем возникло противоречие в ходе рассуждения. Ведь необязательно результат должен быть положительным - негативный дает постановку проблемы и потребность понимания ее причин

4848
Хотел сразу отметить некоторый момент. Часто используется понятие модель требований. Это понятие довольно часто встречается и в иностранной, и отечественно литературе. Так же прослеживается и в case-инструментарии.

В очень интересной книге по требованиям: Элизабет Халл, Кен Джексон, Джереми Дик. "Разработка и управление требованиями"
<< Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней. Моделирование поддерживает наиболее творческий процесс - разработку реализации системы, выработку конкретных системных решений. Моделирование помогает инженеру уточнять и детализировать реализацию системы путем разбиения ее на компоненты при движении вниз от одного уровня требовании к другому. Требования это полный «снимок» того, что именно требуется от системы на каждом уровне. При этом детализация «снимка» увеличивается при движении вниз от уровня к уровню.>>

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

Неплохо бы прикрепить возможность комментирования прямо в статье

4850
80 просмотров и ни одного критического замечания. 1 отзыв в стиле "ЙОУ". кто знает, что это может означать?
Сережа, я честно не осили еще статью. Просто есть другие приоритеты. Почитаю выскажусь :-)

4851
1. Для того, чтобы понимать порядок и состав работ по созданию требований. В контексте разработки ПО.
В контексте создания какого ПО? Судя по твоим отзывом ПО у тебя особенно.

Цитировать
2. Процесса никакого не заложено, отражены зависимости, влияния. Не для любого процесса и методологии, т.к. каждая из них предлагает собственный набор артефактов, их содержания и
зависимостей. Заложена продуктовая специфика - приоритетность внешнего дизайна над остальными аспектами качества, что отражено в порядке работ.
Учитывая, что ты рассматриваешь веб-системы, либо системы с приоритетностью веб-интерфейса, хотелось бы понять, что это значить приоритетность интерфейса? Приоритентность над функциональностью, атрибутов качества, архитектуры? Если так, то как это понимается?

Цитировать
3. Под техническим заданием (на развитие системы) в нашем случае я как раз в форме диаграммы предлагал понимать совокупность функциональной и технической спецификации.
В таком случае на кого рассчитано это техническое задание? Почему спрашиваю - потому как техническая спецификация - это уже часть проектного решения.

Цитировать
4. Архитектура накладывает ограничения на функциональную спецификацию, последнюю нельзя создавать в отрыве от неё.
С учетом предыдущего пункта можно ли понимать так, что используются некие готовые инструменты(cms, lcms, wiki ...)

Цитировать
5. У нас нет требований эргономики, вместо них сразу идёт дизайн. Можно пытаться называть это прототипами форм электронных документов, но, во-первых, это не прототипы, а окончательный дизайн, во-вторых, экраны развлекательного сайта имеют мало общего с понятием "форма электронного документа".
Пусть так, однако наверняка у вас будут интерактивные формы, меню навигации, догика перехода. Разве она не должна учитывать аспекты usability? По крайней мере, tolldo навел на наш сайт критику именно из-за некорректного usability (по форме регистрации)

Цитировать
6. Вопрос не понял. Это из серии - имеет ли смысл фиксировать требования.
В смысле, а нужно ли тратить усилия на него? По крайней мере в таком формализованном виде...

4852
Хотелось бы задать вопрос:
1. для чего существует потребность такой взаимосвязи? Т.е. в каком контексте?
2. Какой процесс разработки ПО или ИТ системы заложен в данную взаимосвязь или эта модель применима к любому процессу, любой методологии?
3. Что в данном случае понимается под техническим заданием? Понятие ГОСТ или какое-то иное понятие?
4. Несовсем понятно направление стрелки от описания архитектуры к функциональной спецификации
5. Где место требованиям эргономики (usability)? Они представлены как я вижу только дизайном (причем это явно прототипы форм так называемых форм электронных документов)

6. Вообще имеет ли смысл составлять такое ТЗ, т.е. имеет ли смысл фиксировать это документально?

4853
Сань! а ты дампишь сайт и форум?
очень бы надо хоть раз в месяц. А то всякое может быть! Главное, чтобы у нас это хранилось а не у них на серверах на всякий случай.
Нужно не забывать дампить и файлы

4854
Агава опять жжет:
Что ж тут поделаешь - фоксмажорные обстоятельства

4855
Анатолий, Ваш прогноз оказался на высоте!

Ну и как всегда, по закону Парето, именно 20% сделали 80%!

4856
Спасибо, Shur. Интересный комментарий и дельные советы.

Могу добавить, что год назад уже возникала потребность в системе документооборота и отслеживании выполнения поручений. Все началось с того, что было поручено просмотреть ряд сущестующих решения: Ефрат, 1С:Архив, PayDox.
Однако сразу стало ясно, что нет измереямых критериев для выбора, так как не понятно зачем они, эти системы вообще нужны. И какую цену готов платить Заказчик.

Была высказана мысль, что директор недоволен как исполняются поручения, т.е. часто бывает так, что поручение дано, но оно не исполняется. Когда производится расследование, якобы оказывается, что поручение не дошло до адресата, либо он (ах гнев на мою голову) забыл о поручении, либо он его все-таки выполнил, но не сообщил или сообщил, но сообщение затерялось.

Также говорилось, что бывает потеря некоего приказа. Либо неясно в каком он состоянии находится и главное у кого. Это касается приказов, которые требуют многоуровнего согласования и подписи. В результате руководитель, ставящий окончательную подпись, вынуждает печать новый приказ, дает нагоняй... до следующего раза...

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

4857
С какой целью ты склоняешь его к комплексному обследованию, когда оно ему не нужно?
На мой взгляд, заказчик не совсем понимает, почему нужна общая картина. Возможно я не прав. Вообще, я уже писал, что у заказчика нет четкой цели что-то изменить. Вернее так, к примерам внедрения ИС в других подобных организациях он присматривается, но считает их дорогими.

Цитировать
Допустим, заказчик адекватен, вот и решай его проблемы, зачем тебе что-то еще?
Допустим он адекватен. Однако каковы его проблемы? Кажется они озвучены, но вряд ли понятны. Да есть у него проблема с отслеживанем поручений, но так ли страшная эта проблема, что она приводит к необходимости каких-то затрат, и вообщем не таких маленьких. Как это понять? Отслеживание поручений затрагивает все аспекты деятельности организации. Заказчик например считает, что это важно. Лично я испытываю в этом большое сомнение.
Ну смотрите. Допустим прелагается некое решение по отслеживанию выполнения поручений: приказы, поручения, распоряжения и т.п. Что здесь важным будет является: генерация исходящего директивного документа, поступлдение его адресату, фиксация получения документа, отслеживание времени работы с документом, отслеживание кто и почеу удерживает документ и не исполняет поручение и т.п. Что вызывает внедрение такой системы - полную перестройку работы с документом, исполнители должны приобрести привычку работать с документами в таком режиме, нужно предусмотреть систему подтверждений. Вопрос, а нужно ли это? Иногда да, иногда нет. Причем пока чаще второе. При этом потребуется очень активная реорганизация и структуризация всего этого.
Потому - как можно все это оценить без комплексного обследования?

Цитировать
Тебе не нужна картина в целом, ты предлагаешь решение конкретных проблем.
Я уже переговорил с рядом людей, проблемы у всех разные. Разное их понимание и представление. Мне же нужно понять какие проблемы самые актуальные, в чем их причина. пока очевидной является рутинность работы, большое количество ошибок и несогласованность рабты отдельных подразделений где используется общая информация.


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

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

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

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

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

Однако в ходе последующих интервью хотелось бы придерживаться более строгих тем и правил. Тут сразу вопрос. В книгах я читал о правилах, но они достаточно схематичны. Нельзя ли привести ряд вопросов или примеров интервью, что нужно сделать готовясь к ним?


Цитировать
Предлагаемая цель обследования, которое Вам необходимо провести: "Выявление целей и проблем Заказчика".
1. Предлагаете Заказчику сформулировать проблемы
Интересно спросить, как правильно задавать такие вопросы. И какие должны быть вопросы? Каковы ваши проблемы? Что мешает вам работать? Что раздражает вас в работе? Что делает вашу работу не комфортной? Чтобы вы хотели изменить? - Не являются ли эти вопросы слишком прямолинейны?

Цитировать
2. Сформулированные проблемы подразумевают, что они возникают в ходе деятельности Заказчика. Предложите Заказчику уточнить, при достижении каких целей у него эти проблемы возникли. Попробуйте выяснить историю их возникновения.
Очень хорошая рекомендация

Цитировать
3. Дальше самое интересное - заявленные цели могут с Вашей точки зрения не соответствовать заявленным проблемам. Обсуждение этой неувязки может заставить пересмотреть список проблем и целей и связи между ними. Важно держать фокус на деятельности именно Заказчика, при попытке обсуждать профессиональные проблемы в широком смысле фиксировать их, но аккуратно возвращать собеседника к тому, как они связаны с конкретной деятельностью (процессами) его организации.
Получилось так, что Заказчик посетовал, что мы хотим слишком абстрактно посмотреть на ситуацию, а ему мол хотелось бы решить вопрос с регистратурой, работу архива. А я вроде хочу сначала увидеть всю картину в целом. По мнению Заказчика - я витаю в облаках ( просто между Заказчиком и мною есть некоторые личные отношения)

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

Цитировать
Важно: Наверное, всё-таки такому обсуждению должно предшествовать изучение:
1. медицинских практик, аналогичных интересующей Вас
2. предлагаемых для них решений.
Да я тоже так полагаю и активно изучаю ряд документов, просто наблюдаю некоторые процессы

Цитировать
Насколько я понял, Вы эту работу фактически сейчас ведете. Возможно, если Вы найдете ответы на п.2, может оказаться, что Вам предстоит повторить какое-нибудь уже существующее решение. В любом случае, наиболее эффективным интервью с Заказчиком будет после того, как у Вас уже сформируется представление о рынке продукта, который Вы хотите создать.
Но важно, что использоваться эти референтые модели должны при интервью на тему "цели-проблемы" не для предложения решений Заказчику, а как некая карта, представление о деятельности Заказчика для выявления его целей и проблем в ходе обсуждения с ним.
Т.е. можно идти с таких позиций. Построить некоторые варианты решений и предложить их для обсуждения с заказчиком, убеждая его в возможности что-то изменить и улучшить? И в ходе обсуждения пытаться выявить глубинные мысли по этим вопросам?

4859
В прошлую среду 10.10.07 состоялось очередное зачетное занятие. Напомню тема вторго задания составить контекст задачи.

Задача впрочем у всех примерно одинаковая. На вводном занятии этого цикла объяснил общие правила и приемы работы с BPWin и составления контекстной диаграммы. Для примера была взята аналогичная задача и рассмотрена референтная модель с сайта http://finexpert.ru. Немного переделанная, упрощенная и адаптированная.

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

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

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

Далее определяются выходы каждого блока, начиная с уровня А0. Затем управление, затем входы и наконец механизмы. Входы, управление, выходы и механизмы, уходящие за границы А0 мигрируются на верхний контекст и таким образом определяют границы системы с данной точки зрения.

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

В день зачета 1 группа была выделена в роль судей - наблюдателей. Другая должна играть роль обвинения, т.е. критиковать полученную модель. Третья выступает в роли адвоката. Выступающая группа в роли ответчика. Обвинение, адвокаты и ответчики меняфются местами. Группа наблюдателей-судей нет.

К сожалению 2 из 4 групп не были готовы. Конечно, виноватым оказался преподаватель. Неготовы оказались группы моего преподавателя-партнера.Якобы он им ничего не сказал. Это при том, что на протяжении каждого занятия я неднократно говорю, все задания, рекомендации по его выполнения, дополнительная литература выложены на сайте(к которому они имеют доступ).

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

2 группа подготовила тоже неплохую презентацию. Сумели выделить наиболее важные детали и убедить аудиторию в этом. Выступление было живым, чувствовалось, что участники активно работали вместе, хорошо ориентируются в материале. Также как и первая группа, забыли о цели моделирования и точки зрения. В отличии от 1 группы мало уделили внимания документированию модели. Т.е. не зафиксировали практически ни в каком месте детали модели.

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

Обсждение каждой презентации показало, что у ребят не так уж мало знаний, опыта и собственных вполне правильных суждений на ситуацию. Практически 80% замечаний, и поощрений были более, чем справедливы. Группа наблюдателей (правда только 2 из нее) дали неплохой анализ и высказали мысли, которые я описал в общем выводе. Более того они дали оценку  группе обвинителей и группе адвокатов. В частности заметили, что некоторые выступающие делали неконструктивные замечания, а защищающие порой не приводили аргументов в защиту своей точки зрения.

В эту среду т.е. 17.10.07 ожидаем выступления отстающих групп, посмотрим сумели ли они сделать какие-то выводы :)

4860
Хорошим аргументом для первого заказчика может быть ТЭО с обоснованием внедрения.
Именно на этом пока все и построено. То есть техникоэкономическое обоснование решения, правда несколько замаскированное под отчет об обследовании.

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

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

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

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

Идеальным вариантом наверное тут является пример конкурентов. Типа вот смотри твои конкуренты не дремлют, вот сделали систему и используют ее на зависть другим, себе на удивление. Но это уже политика, наверное, это уже не моя работа.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »