2005年8月2日のブックマーク (4件)

  • 極私的 打ち合わせのやり方 - IT Architect会議室

    まぁ経験はあるのですが。こういった場合の私の鉄則です。 踏みます。踏み潰します。踏み殺します :-P まず「問題がない」に関しては、後日にでも「詳細な問題点の洗い出し文書」 を差し上げます。無論そのまま開発してもいいのですが「問題点については 発生しても責任取らないからね」と一蹴します。 大抵の場合「セキュリティ的に問題があり(最大被害範囲と社会的影響までを 記述しておくとベター)」「業務上のバグの可能性があり」「システムが破綻 する」恐れがあります。 多くのクライアントはここで怯みます(笑 金がかかる。ええ困った問題です。これについては後述。 二次開発。困りますねぇ。一次の使えないものを「そのまま使う」事と 「改修する事」とを天秤にかけて、より問題のないほうを選択します。 無論、必要に応じては「全部実装しなおします」。 もちろん、その前に「全実装しなおしのほうがメリットがある」ことを ち

    hide_log
    hide_log 2005/08/02
  • 「なぜ「スケジュール」を立てなければ行けないの?」(1) アーキテクチャ - @IT

    はにまるです。 なぜ?なぜ?シリーズ第3段(管理版)です。 今回は、「スケジュール(計画)」 これまた、基的な話ですので、どなたでも、個人的見解を述べれると思います。 1,2年目でも「スケジュールを引け」と言われていますよね? 理由は何と伺いましたか?貴方はどう思いましたか? また、3年目以降の方々も後輩に何度も 「スケジュールを引け」「スケジュールを引け」と言っていませんか? 完璧な返答は要りまん。 あなたの答えは、今年社会人になった方の為の返答です。 あなたの答えは、基礎的な仕事の仕方を飛ばしてきた方の為の返答です。 あなたの答えは、これから管理者、リーダを目指す若しくは成る方への基的アドバイスです。 あなたの答えは、小難しい管理技術論に追われ基礎的な事を忘れた方の為の返答です。 では、教えてください。 なぜ「スケジュール」を立てなきゃ、いけないのですか? 【当スレッドでの注意事項

    hide_log
    hide_log 2005/08/02
    進捗管理 疑問
  • http://www.kokuyo.co.jp/yokoku/master/collabo/index.html

    hide_log
    hide_log 2005/08/02
    コラボレーション プレゼン
  • ダメなユーザインタフェイス講座

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    hide_log
    hide_log 2005/08/02
    ajax ユーザビリティ